Today we’ll talk about Dynamics 365 (D365), role-based security, user-based security, Security Roles, and Field Security Profiles.
Let’s first look into the definitions in security types.
- Role-based security:
- Roles make it easy to assign the same set of permissions to multiple users based on job function. Role-based security allows for easier management and administration. Role-based security is better used for clearly structured hierarchies, common groups, and defined information-sharing policies. Role-based permissions are the most efficient way to manage permissions.
- User-Based Security:
- User-based access allows more granular control of the system. However, such control can entail increased management work, as any changes to permission settings usually have to be done for each user. If you want to specify exactly which parts of a system or each user can access, you will use user-based security. User-based security is also used for highly flexible team roles would likely prefer this type of permissions.
- Field Level Security:
- It is used to restrict access to specific high business impact fields in an entity only to specified users or teams. This applies after privileges have taken effect.
- Layered Security:
- These roles are added to a user as the user advances through the organization, they get more and more access to the data.
- For instance: Training Role, Entry-level, management, administration roles.
- The theory behind the layered security role system is, that you create a baseline role shared by everyone, and then add roles to users who move up the hierarchy.
- Each role opens more access to the system and data.
- As long as you create those departments at “Business Units” in D365 and then assign each user to the appropriate business unit, Level 1 is level 1 whether a user is in sales, marketing, or service.
- These roles are added to a user as the user advances through the organization, they get more and more access to the data.
- Non-Layered Security:
- These roles operate independently of one another.
- Non-layered security roles allow you to match access levels and privileges to specific job descriptions rather than to an overall hierarchy of access.
- For example: Create roles with specific access levels and privileges for Teams like Sales, Sales Manager, Customer Service, Marketing Managers, VP’s, Executives.
- Level 1: Training role with extremely limited access
- Level 2: Entry-level role with read access to business unit records and full access to user-owned records
- Level 3: Management-level role with read access to all records and full access to business unit records
- Level 4: Executive-level role with read access to all records
- Level 5: Administrator role with full access to all records
- *** Notice Level 4 loses privileges granted to level 3
Now that there is an understanding of how role-based security works, let’s dig in and talk about how best practices using role-based security works in D365.
Security Roles:
How to use role-based security to control access:
- Use role-based security to group common sets of privileges together, these can be used with a Business Unit or a Team.
- Privileges define the ability to create, read, write, delete, assign, and share records of a specific entity.
- Each privilege has an access-level tied to it, for a given entity. Access-levels are Global, Deep, Local, Basic, and None.
- Using role-based security, there will be security dependencies, for instance:
- Creating a record – Create, and Read
- Assign a record – Read, Write, and Assign
- Sharing a record – Read and Share
- Append a record – Read, Write, and Append
- Append To a record – Read, Write, Append To
Field Level Security:
Using Field Level Security to control access:
- Field level security is managed by the Security Profiles.
- Every field in the system contains a setting for whether field security is allowed.
Security Profiles:
A security profile determines the following:
-
- Users and Teams
- A security profile can be configured to grant a user or team members the following permissions at the field level.
- Field Permissions
- Read: Read-Only access to the field’s data.
- Create: Users or teams in this profile can add data to this field when creating a record.
- Update: Users or teams in this profile can update the field’s data after it has been created.
- Combinations of the Field Permissions can be configured to determine the user privileges for a specific data field.
- Users and Teams
How do you know what permissions you have on the field?
-
- Secured: The field would have a “Key” icon next to it.
- Read-Only: The field has a “Lock” icon next to it
- No Permissions: The field will have seven asterisks in the field
**** I will create a future blog on how to setup Security Profiles.
Best Practices for Field Security
- When you use fields and what that specific field to be read-only.
- Some data uses multiple fields, so make sure to enable field-level security in all fields. Example: Addresses
- In order to allow a user to edit only one field on a form, you will need to enable field security on all fields on the form in question.
- Make sure to set up additional Security Profiles for additional Business Units and Teams that need permissions to the fields.
Best Practices for Modifying Security Roles
- Do NOT modify the Out of Box Security Roles
- Copy the role then modify and implement
- This will avoid potential issues with future updates as well as a point of reference
Security Design Tips
- Create your organization hierarchy
- Plan out your Business Units, Teams, and what entities they need access
- Business Units: Executives, Operations, Finance, Marketing, Sales
- Teams: AR, AP, IT, HR, Partners
- Entities: Accounts, Contacts, Marketing, Partnership
- Understand what fields will need field-level security enabled
- Always have the security model in mind
- Always plan for the future
- Keep it simple: Less management, Administration
- Clean up all potential security risks
- Document and keep your team on the same page
G.S.D. 