web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics CRM (Archived)

Use of InheritedAccessRightsMask in PrincipalObjectAccess Table

(1) ShareShare
ReportReport
Posted on by 20

Today, I came through an issue from one of a CRM User who do not have share on an Opportunity, but he is able to view that. I tried all possible ways to revoke access for the Opportunity from the user, but did not succeed.

After analysing the PrincipalObjectAccess table, i found that that AccessRightsMask is set to 0 for that Opportunity, but InheritedAccessRightsMask has a non-zero value. The only option now is to manually set the InheritedAccessRightsMask value to 0.

Is there any other way to achieve this?

Can any one give me some idea on the InheritedAccessRightsMask column? When/How is it set and used by CRM?

*This post is locked for comments

I have the same question (0)
  • Jeremy Winchell Profile Picture
    1,165 on at

    Bhuban,

    I am running into the same exact issue.  The only resolution I found was to set that field to 0 in the POA table.  I've put all of the Cascading rules back to the OOB default and still can't get it to work.

    I also tried sharing the Opportunity again and then revoking without any luck.  I'm going to adjust more of the cascade rules to see if I come across anything.

     I will let you know.  Hopefully we can get an answer on this.

    Jeremy

  • Community Member Profile Picture
    on at

    Guys,

    I need your help urgently:). Basically I have similar issue.

    Lets say I have Campaign A created by user User1. Now when I login as CRM Admin and create a planning task and assign it to User2, User1 being owner of the Campaign gets complete access to this task although role of User1 has neither read nor write access to other people's tasks. When I check DB, inheritedaccessrightsmask for the object is set to non-zero value which should be for CRM Admin not for User2. In other words, although CRM Admin has reassigned this task to User2, its inheritedaccessrightsmask is not reset. If I login as User1 and create a task for User2, I immediately get access denied and task is created for User2 on which User1 has neither read nor write access.

    Since my workflows are running as CRM Admin, it is happening with all tasks and Campaign owners can play with approval tasks which is not good. I have reproduced same thing in all of my 3 environments.

     Can anyone help me?

  • Jeremy Winchell Profile Picture
    1,165 on at

    Akif,

    What you'll need to do is change the Cascading relationships on Campaigns.  The Share/UnShare will execute when the parent record is shared.  The issue is with the Reparent Cascade behavior.  The Reparent is actually what takes care of granting rights when a new child record is created, like a Task.  If the Reparent is set to Cascade All, when you create a new Task/Activity under a parent record (Account, Contact, Campaign etc), the Reparent rule grants the Owner of the parent record access to the child. 

    I found this out after I created a Team Based sharing system for another client, hence the same question I posted a bit earlier on this thread.  It definitely isn't crystal clear and it's not document in terms of what it does in regards to sharing.  So I what you could do is set the rule to:  Cascade None for Reparent and that should take care of the problem.

     Jeremy

  • Community Member Profile Picture
    on at

    Hey buddy, Thanx. It worked for me!!

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans