Before reading the post, you may would like to read the official document on Microsoft at https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/assign-entity-permissions. This will give you a basic understanding of entity permissions in Microsoft CRM Portal.

Your customer wants to build a portal using Microsoft CRM portal. Connection is used for linking their contacts and accounts. Your customer wants to control the permissions of their contacts (who will login to the portal) on their related accounts, based on their connection role. If a contact is assigned as Admin role, he should be able to edit the account record. But, if it is User role, he should have read-only access to Account record.

Using connection to assign role to accounts

Sounds like a familiar request from most customers?

If yes, let’s look at how we can implement this scenario in Microsoft CRM portal.

Problem

I hope you have already read the official document link described at the beginning or you are familiar with Entity Permissions and its Parental scope. Then, you will quickly realise it is not possible using only Connection entity, because you cannot set different permissions based on role assigned.

Entity permission of Connection

Parental scope only handles a relationship between entities. For instance, it is only interested in determining whether a contact has relationship with Connection, and Connection has relationship with Account. It does not take care of Connection role.

As a result, you cannot set different privileges on same relationship.

Now, you know the limitation of Parental scope in Entity Permission.

Solution

It is quite simple. You need to create custom entity for each role, on top of using Connection. In this scenario, you need to create two custom entities; AccountAdminRole and AccountUserRole. Now, you can create two different Parental scope entity permissions, each having different privileges.

Setup following entity permissions.

Entity permission of AccountAdminRole

Entity permission of AccountUserRole

Create following records.

Setting up AccountAdminRole record

Setting up AccountUserRole record

You now have correct access permission; 1) edit privilege on A. Datum account and 2) read-only access on Adventure Works.

You may ask why we are still using Connection if two custom entities will sort out the issue. Well, it depends. Using Connection, at least, it gives you a single view contact’s role. However, you will need to use a workflow/plugin to auto-create/auto-delete the records in custom entities.

For instance, when a contact, Aung Khaing, is linked to an account, A. Datum, as an Admin, your workflow should create a new record in AccountAdminRole entity. When my role is changed to User, the workflow should remove an existing record from AccountAdminRole and create a new record in AccountUserRole entity.

Another drawback is the number of custom entities you need to create is same as the number of roles you are going to have. If you have 10 different roles, you need 10 different entities.

I accept the solution is not so elegant. But, it fulfils requirements and purpose without reinventing the Entity Permission framework of Microsoft CRM Portal.