Dynamics 365 Portals has a powerful user permissions system out of the box, enabling your organisation to control who gets access to your information. In this guide, we're going to discuss the settings for web role permissions to get you up and running
and provide some pointers on ensuring your data is secure and only available to users you want to see it.
In Dynamics 365, each user fits in a permission category called Web Roles. The default roles include Administrator which grants users in this role to make fundamental content and design changes to the portal. You then have roles such as Event Managers,
Blog Authors and Self-Service Users which are more restrictive but enable access to specific data.
You can create new web roles which you can customise to your requirements. To do this, navigate to Portal > Web Roles and click the "+ New" label on the top left of your screen.
On this new view, you'll be able to define the scope of the permissions using the Entity Permissions table. You can also select if it applies to registered or premium users under Content Access Levels table and you can also select the users
who have this web role.
Selecting users to fit the web role
Scroll down towards the bottom of your web roles screen and navigate to the Contacts table.
If its an existing web role you will likely see a list of users already attached against this web role. To remove a user, highlight over the top
We suggest having a web permissions strategy planned before setting up the portal with your project managers and security personnel such as GDPR data protection officers. It's best to know exactly who should be having access to what information beforehand
so you can ensure you are GDPR compliant.
To add or remove specific permissions we'll need to examine Entity Permissions view which you can find under Portals in your CRM. You can edit the entity permissions that already exist, or create a custom one if you have a highly specific permissions
setting to implement.
When editing or creating a new case, it's important you select the appropriate Scope option for your requirements.
The options you can choose from the drop-down field box are:
If an Entity Permission record with Read permission is granted to a role that has global scope, any contact in that role will have access to all records of the defined entity in Dynamics 365. For example, they will be able to see all leads, all accounts,
and so on. This permission will be automatically respected by any entity lists, essentially showing all records according to the Dynamics 365 views that have been defined for that list. Further, if a user attempts to access a record via an entity form
that they do not have access to, they will receive a permission error.
With Contact scope, a signed-in user in the role for which the permission record is defined will have the rights granted by that permission only for records that are related to that user's contact record via a relationship that is defined in Dynamics
On an entity list, this means that a filter will be added to whatever Dynamics 365 views are surfaced by that list, which only retrieves records directly linked to the current user. (Depending on the scenario, this relationship can be thought of as ownership
or management rights.)
Entity forms will only allow the appropriate permission for Read, Create, Write, and so on if this relationship exists when the record is loaded. More information: Define entity forms and custom logic within the Dynamics 365 portal.
With Account Scope, a signed-in user in the role for which the permission record is defined will have the rights granted by that permission only for records that are related to that user's parent account record via a relationship that is defined in Dynamics
Self Scope allows you to define the rights a user has to their own Contact (Identity) record. This allows users to use entity forms or web forms to make changes to their own Contact record linked with their profile. Note that the default Profile Page
has a special built-in form that allows any user to change their basic contact info, and opt in or out of marketing lists. If this form is included in your portal (which it is by default), users will not require this permission to use it. However, they
will require this permission to use any custom entity forms or web forms that target their User Contact record.
In this most complex case, permissions are granted for an entity that is a relationship away from an entity for which an Entity Permission record has already been defined. This permission is actually a child record of the parent entity permission.
The Parent Permission record defines a permission and scope for an entity (probably Global or Contact scope, although Parent is also possible). That entity might be related to a Contact (in the case of Contact scope) or globally defined. With that permission
in place, a child permission is created that defines a relationship from another entity to the entity defined in the parent relationship.
Thus, users in a web role who have access to records defined by parent entity permissions will also have rights as defined by the child permission record to records related to the parent record.
In the image above, we're looking at the entity permission for Blogs. As you'll be able to see, when web roles have this entity permission attached, they'll be able to:
- Read blogs and blog posts
- Create new blogs
- Delete blogs
- Create new blogs
- Change blog content
This is because each of the privilege options is ticked in our example.
Dynamics 365 Portal has plenty of out of the box permissions for different entities, but of course, if you have a specific application you may need to create a new record for a custom entity.
Dynamics 365 Portals was created to help organisations provide its users with a self-service interface, which cuts customer service costs and delivers convenience. In order for that to be possible, customisable security permissions are critical to ensuring
self-service users data is safe, and permissions are tightly controlled. D365 Portals are packed with security capabilities, and in a future post, we'll also cover Web Page Access Controls and Website Access Permissions.
We would like to reiterate the importance of planning your portal permissions before launch, as reversing decisions later can be problematic.