Restricting access to records based on a field?

(0) Share

Report

Posted on by ToniG

321

Is there any way to say that a user can only see records if a field is not null? I have an outside partner who wants access to our CRM, but we only want them to be able to see records that are "tagged" as theirs, by having a value in a field. It's not possible or plausible to change the owner of the records to this user, and their access need would cross between leads, opportunities and activities.

Just wondering if anyone had any thoughts on this? Is it even possible?

Thanks!

*This post is locked for comments

All responses (3)

Answers (2)

Verified answer

anonsgate 420 on at

Like (0)

Report

RE: Restricting access to records based on a field?

Make a Team of type Owner in Settings -> Security - > Teams

On records you want to enable, do Share. Choose user/team and choose your team.
Community Member Microsoft Employee on at

Like (0)

Report

RE: Restricting access to records based on a field?

It seems the only way is to develop a plugin which handle Retrieve and RetrieveMultiple messages so each time a record is retrieved you can check the field value.

Hope it helps.

If you found the answer helpful, please mark as Verified

Thank You & Best Regards

Francesco Picchi

Microsoft Dynamics CRM Consultant, Bologna, ITALY

Independent Contractor

http://www.francescopicchi.com
Verified answer

Daniel Wikell 2,360 on at

Like (1)

Report

RE: Restricting access to records based on a field?

Technically you could develop plugins on the Retrieve and RetrieveMultiple messages and filter the records returned based on the combination of the user requesting them and a certain field value. These plugins would probably cause a hit towards the performance and would likely not be the preferred way to do it though.

Have you looked at Access Teams? It sounds like you could solve this by enabling access teams for these record types and then just add the user to each access team of the records that the user should be able to access.

See the Access Team parts of this page for reference: msdn.microsoft.com/.../dn481569.aspx