Restricting access to records based on security roles and other criterias

(0) Share

Report

Posted on by Henrik notlev

Hi there.

I would like to use the Account entity to hold ALL our different kind of accounts. In fact this is suggested by CRM it self in the field "Relationship Type", where you can set the relationship type of an account to Customer, Prospect but also to Supplier, Vender and others.

It should be obvious to all that not all kind of accounts are relevant or permitted to all users. So is it just me or why is there no way to limit a users access to search, filter and see details of accounts and even to prevent seeing data using Advanced find, based on a combination of i.e. the Relationship Type and a Security Role?

I feel forced to create new business units just for this purpose. That seems a bid stupid.

Has anyone found the way?

Have Microsoft plans for this?

*This post is locked for comments

I have the same question (0)

All responses (11)

Answers (0)

Suggested answer

Aric Levin - MVP 30,190 Moderator on at

Like (1)

Report

Unfortunately I think you are stuck.

We just had the same issue with one of our clients, and had to go the business route and team way.

We assigned ownership of the records to teams under different business units to restrict access, so this is definitely not ideal.

You would also have to consider based on that to what business units your users will belong to.

If this does not fit your needs, there is another option.

You can create plugins for the RetrieveMultiple and Retrieve functions that will display only the records that you want displayed.

You will kind of have to implement your own security.

For example: User A can only see Prospects.

You would have a mapping table between Users and "Record Type";

When the retrieve multiple plugin executes, you would bypass the original, and change query that is returned to only show Prospects to the user.

I hope this helps.

Was this reply helpful? Yes No
Suggested answer

ashlega 34,477 on at

Like (1)

Report

I think business units is the easiest option.

Using the plugins is an option, but, unfortunately, there is a bypass.. which is called FetchXml SSRS reports - they just completely ignore those retrieve multiple plugins. This is not to mention all the complexity of updating the filters correctly (which seems to be relatively easy to do if you start with accounts.. but what if you start with contacts and link the accounts, and what if the filters are more complex..)

And yet another option is to use sharing (possibly through the access teams.. which can be somewhat automated using plugins.. you would use a plugin to share accounts with the teams/users based on more or less the same rules Aric just described for RetrieveMultiple plugins)

Was this reply helpful? Yes No
Suggested answer

Henry J. 5,237 on at

Like (0)

Report

Henrik, you really should get to know the security model better.

Relation types have nothing to do with security (and never will).

You already find part of the answer: create a business unit hierarchy where you can dispatch both your users AND your data (through their owner).

In your case, I would assign the Account records to teams belonging to different Business Units (one per type of account?).

Then, depending on the complexity of your model, I would add the users to the appropriate teams, opening up visibility to account records of the various types you described.

Was this reply helpful? Yes No
ashlega 34,477 on at

Like (0)

Report

I would agree with Henrik though.. No matter what the specifics are, out of the box security is not good enough in some cases..

Was this reply helpful? Yes No
Henry J. 5,237 on at

Like (0)

Report

I don't know about that.

To me Dynamics security model is quite extensible and offers many options: business unit hierarchy, security roles and teams, hierarchical security, sharing, field level security, access teams, relationship behaviors...

So I feel like it can cover many use case but at the same time be quite complex to configure (with all its different options and considerations to take into account).

Was this reply helpful? Yes No
ashlega 34,477 on at

Like (1)

Report

You cannot "deny" access, and that's kind of the missing piece since you have to come up with all sorts of artificial workarounds for that. There is a very simple example: it's normal to have "read for everyone" security model.. However, if a CRM user has a conflict of interest in regards to the specific records.. imagine revenue agency department.. where all employees should be able to access all data.. but, every now and then, somebody should not have access to a specific tax file because that CRM user has personal relationships with whoever that tax file is linked to.. From the out-of-the-box security model perspective, it's a dead end. You end up with exactly the same question which Henrik is asking above.

Was this reply helpful? Yes No
Henry J. 5,237 on at

Like (0)

Report

Yes I'd have to agree on that one ;)

It can be quite a headache to deal with exceptions!

Was this reply helpful? Yes No
Henrik notlev on at

Like (0)

Report

Hi Henry, I think I know the security model well enough to see we have an issue.

I specifically asks why there is NO WAY to combine e.i. Relationship Type (a filed) with security roles.

Using business units creates a whole new level of complexity because most users will have to exist in more units.

But I agree that would be one way to go.

Was this reply helpful? Yes No
Henry J. 5,237 on at

Like (0)

Report

I get your point and I'b happy to upvote any improvement suggestion on ideas.dynamics.com/ideas

Was this reply helpful? Yes No
rath.amit38@gmail.com 2 on at

Like (0)

Report

Hi,

What is the final solution to this? What should be our approach to get the optimum solution?

Thanks

Amit Kumar Rath

Was this reply helpful? Yes No