Manage Security Roles Overview

So it may sound quite simple, but security rules are really quite a vital part of the experience for a user. It defines their experience. It defines the things they are allowed to do once they are there in the application. So security rules offer privileges. Each security role consists of record-level privileges and task-based privileges. Record-level privileges define which tasks a user with access to that record can do, such as read, create, delete, write, share, append, and append to. Append, for example, means to attach to another record, such as an activity or a note to a record. Append to means to be attached to a record.

Task-based privileges, typically reside at the bottom of the form, give users privileges to perform specific tasks, such as to publish articles. Some key concepts to bear in mind when we’re talking about security roles is user access is determined by the combined privileges of all assigned roles. This gives the user the most access. Another way of putting this is the security rule privileges are cumulative. Having more than one security role gives a user every privilege available in every rule. This gives you a few different opportunities for layering of roles, combining permissions, and things of that nature, which we’ll learn about more in a later lesson. By default, new custom entities have no access for most users.

System administrator and system customizer will have access. A user will need to have at least one security role assigned to be able to access the application. We’ll learn more about users and teams and how they can have many similarities as we move along. And we could also add security roles to tailor the user’s experience using role-based forms. There are a few ways to manage the user’s access. You can change the access component, editing a role, add a role, or you can work on giving the specific access to a user. Once you have that role, you can assign or remove a role to a user or you can add to remove a user to a team that has a role.

You could add a role either from the grid view of available users just like you would on other Dynamics records. Or you can do it from the open user record. So you would select to manage roles. Then from the options available, select the role or roles, and click OK to apply. Sometimes when we want the user to see this in action after we’ve made these changes, they may have to refresh their browser to confirm that they have the new access that we have assigned. When it comes time to managing the security roles, you can arrive here via the admin.powerplatf orm.microsoft.com area or via the classic app in the security area of settings.

Both of these paths will take you to the same grid view of the available security roles. Once there, you have several tabs available to assign level of access with the selected privilege. Privileges can be summarised as activities that can be performed on a given record. So for example, have the create privilege on the account entity would enable a user the ability to create account records. You can also set privileges and additional actions like appending or assigning records. With each privilege, you are required to assign a level of access that is allowed. We will be covering privileges and access levels in more details later on in this lesson.

So when it comes to level of access, we have a few different options available. We’ll go through each of those in detail now. No access is quite simple. The user has no access to the specific item contained in the role. When that pie is empty, the user has no access. Sometimes this is binary, off and on. Sometimes it is the various levels available, such as user, business unit, and so on. Then we have user access. This access level gives user access to records that they own, objects that are shared with the user, and objects that are shared with the team that the user is a member of.

This is the typical level of access we’ll see for everyday users, sales representatives, customer service representatives, basic application users. This application is also referred to as user application access or Basic access. A business unit is Local access. It gives the user access to records in their own business unit. Users who have this access will also automatically have Basic access as well. It’s cumulative. Because this access level gives access to information throughout the business unit, it should be restricted to match the organisation’s data security plan. This level of access is usually reserved for managers with authority over the business unit. Parent-child business unit access– this is also considered Deep access.

This gives the user access to the records in their own business unit and all business units that are subordinate to that users business unit. Users who have this Deep access will also automatically have the other access points we’ve already discussed, including Local and Basic. Because this access level gives access to information throughout the business unit and the subordinate business units, it should be restricted as well to match the organisation’s data security plan. The level of access is usually reserved for managers and folks with authority over the additional business units. And then we have organisation-level access or Global access. This really does give the individual user for that item pure Global access.

So it gives them access to all records, regardless of the business unit or hierarchical level where they exist. Because this is business-level access throughout the organisation, it should be restricted to those who have reason to have that level of access. It is important to note that if you’re using entity ownership type of organisation owned, you don’t have the levels of access available. You have it’s on or it’s off for those organisation owned entities.