MICROSOFT DYNAMICS 365: HIDE AND SHOW BUTTONS

 In this article, we cover to how to hide buttons as well as how to show buttons that are hidden, in Microsoft Dynamics 365 Customer Engagement. To achieve this object, we will use an example with practical requirements. To implement what is in this article, the user must have a System Administrator security role in Dynamics 365.

Working with Ribbon Workbench for Dynamics 365

If you do not already have the Ribbon Workbench for Dynamics 365, go and download it: Ribbon Workbench for Dynamics 365. The Ribbon Workbench comes as a Microsoft Dynamics 365 managed solution. Therefore, after downloading it, you have to import it in your Dynamics 365 instance by going to: Settings >> Solutions >> Import. After successfully following the import dialogue to the end and successfully importing the solution, refresh the page and you will able to see the Ribbon Workbench button in the Solutions area of Dynamics 365:

Application Example: Hide Buttons

Below we will provide an example of practical client requirements and show step by step how the Ribbon Workbench for Dynamics can help us address these requirements.

Requirements

A national, provincial /state or city level education board that has a Microsoft Dynamics 365 Customer Engagement implementation that keeps track of all the schools and students in its jurisdiction. Each student in the system must be linked to a school and under no circumstance can a user of the system be able to create a student record that is not associated to a school record. This prevents the problem of creating of orphan student records in the system i.e. student records without an associated school record.

Implication of the Requirements

To implement these requirements, we will have to restrict the places where users can access the Student (logical name: contact ) entity’s New button and be able to create new student records. Student records should only be created in relation to a School (logical name: account) record i.e. from the School records’ Students sub-grids as shown in the image below.

• The Student’s sub-grid on Schools’ form
  
• The Student’s sub-grid on Schools’ related entities menu
  
  
  

Therefore, after implementing the instructions provided under the sub-section “Implementation of the requirements” and section “Other Settings”, users will only be able to create student records from the from the Student entity’s sub-grids on the School records. Hence as a corollary, users will no longer be able to create Student records from:

• Quick Create menu
  
• Advanced Find
  
• Student entity’s Home Command Bar
  
• Student entity’s Form Command Bar
  

Implementation of the requirements

1. To Go to Settings >> Solutions, and create a new solution. Add the entities whose ribbons you wish to edit. In our example, we will be adding the Student (logical name: contact ) entity only to the new solution. Exclude all entity assets but include the entity’s metadata. Save and Publish All Customizations.
2. Under Settings >> Solutions, click on the Ribbon Workbench button to launch the Dynamics 365 Ribbon Workbench. Select the solution created in part 1 and click OK.
   
3. After opening the solution in Ribbon Workbench, it will look like the image below. Ensure you are editing the intended entity (A in the image below). In our case, we intend to edit the ribbons for the Student (logical name: contact ) entity. On the Student (logical name: contact ) entity, we intend to hide all the New buttons except on the Student’s sub-grids (B in the image below).
   
4. To hide a button, right click on it and select “Hide”. After hiding all the Student (logical name: contact) entity New buttons, except on the Student’s sub-grid (highlighted in green in the image above), the solution in Ribbon Workbench will look like the image below:
   
5. Click Publish. After the publishing process is done, the only place you will be able to see the New button, in your Dynamics instance, for the Student (logical name: contact) entity is on the sub-grids, as per the requirements above.

Application Example: Show Hidden Buttons

Months or years later, the requirements may change and the client may want to us to reverse the work done in the previous section and show the the hidden New buttons. To accomplish that:

1. To Go to Settings >> Solutions, and create a new solution. Add the entities whose ribbons you wish to edit. In our example, we will be adding the Student (logical name: contact ) only to the new solution. Exclude all entity assets but include the entity’s metadata. Save and Publish All Customizations.
2. Under Settings >> Solutions, click on the Ribbon Workbench button to launch the Dynamics 365 Ribbon Workbench. Select the solution created in part 1 and click OK.
   
3. After opening the solution in Workbench, it will look like the image below. Ensure you are editing the intended entity (A in the image below). In our case, we intend to edit the ribbons for the Student (logical name: contact ) entity. On the Student (logical name: contact ) entity, we intend to make visible the hidden buttons. In contrast to the “Application Example: Hide Button” section, the next time we load an entity in Ribbon Workbench, the hidden buttons are no longer shown command bars section (B in the image below) but are shown under the Hidden Actions section (C in the image below). To make visible these hidden buttons, right click on each button (C in the image below) and select “Un-hide”.
   
4. Click Publish. After the publishing process is done, the “New” buttons that were previously hidden will become visible in your Dynamics 365 instance.

Other Settings

• To fully ensure that there no orphan Student records are created, make sure the Student entity’s School field is set to Required and the field is added to all Student entity’s forms.
• Quick Create: To stop users from creating the Student records from the Quick Create menu, remove the Quick Create option from the entity:
  1. Go to Settings >> Solutions
  2. Open the solution containing the entity
  3. In the solution, click on the entity. Remove the “Allow quick create” option.
     
  4. Save and publish the solution

Role Based Forms and Dashboard – Dynamics CRM

 

What are Role Based forms

Microsoft Dynamics CRM allows configuration of security roles in Entity forms. It is quite a common requirement for organizations where they want users of two different security roles to see different fields and sections.

For ex, a Sales person would want to see only the Sales details on the form and a CEO/ Director wants more details in the form.

Also, there is a possibility that there are 2 product lines which have different set of fields for the same entity.

 

Alternative approaches

From the above requirements, most users will think that the above can be achieved using form customizations or JavaScript on the form.

While this is true, this approach is not a feasible one when the 2 versions of form which we create are a lot different from one another.

JavaScript should be used when there are only few fields which we need to show/ hide on the form based on Security Roles.

How to enable/ implement Role based forms

Using/ enabling security roles in forms is very straight forward, but we have to be careful to set/ remove the roles carefully for each form.

1. I have created two contact forms as below. As you can also see, there is a button on the top of Form section “Enable Security Roles” which we will use to configure form security

Figure 1

1. By default, both forms are accessible to all the security roles. We will now change the security roles for each of the form
2. For “Contact Form”, we will provide access to only CEO – Business Manager, CSR Manager and Marketing Manager. So Users with roles other than these will not be able to access this form.

Figure 2

1. And similarly I will configure the security roles for the “Contact v2” form. We will assign roles Salesperson and Marketing professional for this form.

Figure 3

So we have now created 2 forms which users with different security roles will access. But there are few OTHER things which we need to address before we complete this entire process

Things to consider

When we implement Role based forms, the following questions pop up in our mind, for which I have also mentioned the solutions

Q1. What if the User has 2 security roles and thus have access to both the forms?

A: The User will see both the forms and there is an option for user to choose one of the forms in the Top left corner. Refer screenshot below:

Figure 4

The answer to Q1 will pop up another question:

Q2. If the user has access to two forms, which form will be visible by default to the User?

A: There are 2 parts:

1. User access the Entity form for the very first time

When a User access the entity form for the very first time, the default form which User will see will depend upon the Form Ordering. This can be checked in Entity customizations like below:

Navigate to Form Order à Main form set

 

Figure 5

Figure 6

1. When User changes the Form from the Dropdown

Whenever user changes the Form from the Dropdown, CRM stores the user preference. So when the user logs in next time or navigate to the same entity form next time, CRM shows the form that the user has used previously and will ignore Form ordering for the particular user.

Q3: What if a User has access to the entity but has no Access to any of the forms for his Security Role?

A: CRM is very smart and handles this by using “Fallback” mechanism. When we configure the Security Role for a form, there is a checkbox at the bottom à “Enable Fallback”

As you can read from the Description in the screenshot, this form will be shown to the Users with roles that don’t have any forms assigned.

CRM makes it mandatory to select at least 1 form for fallback.

Figure 7

Q4: What if I don’t want to make any of my forms as Fallback forms?

A: This is a valid scenario as we don’t want the users who are not explicitly assigned any role on the form to see the form.

• As a workaround, we can create one form as a “Default Fallback” form which will not have any form fields (or 1-2 fields) and configure this form to be a fallback form.
• Additionally, we can add a web resource (HTML) in this form which says something like this:

“If you are seeing this form and do not have access to any other form for Contacts, Please contact Administrator.”

• Also, we should keep the Fallback form last in the Form Order.

This is how the fallback form would look like:

 

As for Forms, Dashboards in Dynamics 365 can also be enabled for only a set of selected Security Roles.

Unique ID

As for all records in Dynamics 365, each Security Role is assigned with a unique identifier and can be accessed through the Web API for example. The GUID can be found in the URL when opening a security role in Dynamics 365.
 

There is also an entity called “Privileges” in Dynamics 365. When an entity is created, there are 8 new “Privileges” records that are created – one per security role privilege. Each of these records has a GUID. When a user encounters an issue related to security roles privileges, the GUID is printed in the error log file.

Security in Microsoft World

Security Roles with privileges and access levels are specific to Dynamics 365. Security in other products of the Microsoft Family is managed differently, with each application having its one way to deal with data security and management.
For example, Sharepoint’s security contains Groups, Sites, and sharing capabilities and PowerBi makes usage of “Row-level security (RLS)”.
When combining such products together, the way to handle data security should be analyzed, defined, and discussed.
 

 

---

[1] When changing the business unit of a user, the associate security roles are removed. The user will not have access to Dynamics until a new role is assigned.

[2] While configuring hierarchical security, the parameter “Hierarchy Depth” controls direct manager’s access to the subordinate’s records of their subordinates. Configuring this depth above 5 can impact negatively the performance of the system. Microsoft recommends keeping the effective hierarchy security to 50 users or less under a manager/position.

[3] This Job Position Hierarchy is also used by the button “View Hierarchy”   in the User entity.

Security Roles in Dynamics 365

 Security Roles Overview

To be able to access a Dynamics 365 CRM, any user with a valid license must:

• Be assigned to a Business Unit
• Be assigned to at least one security role[1]

Security Roles define the way users can access and handle data in Dynamics 365. It enables administrators to control access to data and ensure that each user has the information that they need to complete their tasks and nothing more.
With this approach, Dynamics 365 enables to:

• Protect information from being mishandled by users who lack understanding.
• Protect private knowledge from getting into the wrong hands
• Ensure that users have the power to take actions commensurate with their profile/job role.

Security Roles can be seen as a matrix of privileges and access levels for all entities.

Privileges

Privileges enable users to take actions on records. They are the basic security unit that details what actions a user can perform in the CRM.

Allow users to take actions on records.

Create	-	Allows the user to add a new record.
Read	-	Allows the user to view a record.
Update	-	Allows the user to edit an existing record.
Delete	-	Allows the user to delete an existing record.
Assign	-	Allows the user to change the owner of the record, to another user or team.
Share	-	Allows the user to share an existing record. When sharing a record, it’s possible to specify the permission given to the user.
Append	-	Allows the user to attach other entities to, or associate other entities with a parent record (e.g: lookup fields). In case of many-to-many relationships, you must have Append privilege for both entities being associated or disassociated. In one line: when an entity has the lookup of another entity on its form.
Append to	-	Allows the user to attach other entities to, or associate other entities with the record.   In one line: when an entity is available as a lookup on another entity form.
		e.g: A Contact has a lookup to an Account (for example: employer). The user needs to have a security role with privilege “Append” on the Contact entity and privilege “Append to” on the Account entity.

The above height privileges are called “record-level privileges”. They defined which actions a user can do. There are also “task-based privileges”. Those miscellaneous privileges are not linked to an entity directly but operate on specific tasks, such as viewing audit history, publish e-mails, bulk edit, export data to Excel, etc…
In Dynamics 365, task-based privileges are at the bottom of the Security Role form.
Note that it’s not possible to remove access for a given record. Any change to a security role privilege applies to all records of that record type – exception made if the user has been given access to a record via the “Share” functionality.

Access Levels

Determine the scopes a user can perform a given privilege on data.

None	-	No privilege was given. Set by default if nothing specified.
User	-	Privileges to the records owned by the sure or share with the users. It also includes the privileges owned by the team user belongs to.
Business Unit	-	Privileges for all records owned in the business unit to which the user belongs
Parent-Child Business Units	-	Privileges for all records owned in the business unit to which the user belongs and to all the child business units subordinate to that business unit
Organization	-	Privileges for all records in Dynamics 365.

 

 

In Dynamics 365, this is indicated by the degree of fill and color of the little circles against each entity for each privilege.

Example: For the security role below, a user assigned to it can create only its own records – but no records under other user names. But users can delete contacts owned by anyone in their business unit. They can also read and edit any contacts in the entire CRM.

 

Entity Ownership: When creating an entity, administrators need to specify the kind of ownership between “User or Teams” and “Organization”. By default, the value is set to “User or Teams”.

If “Organization” is chosen, it will have an impact on the Privileges and Access levels available. As the entity is owned by the organization, there is no specific owner and no notion of Business Unit ownership.

Therefore, in the Security Roles for those entities:

• Privilege: Assign and Share privileges are not available.
• Access Levels: There are only two scopes available: None and Organization.

 

Business Unit

Dynamics 365 uses Business Units to differentiate different parts of a company that might have different security needs. As such, they are a basic component of the security in Dynamics 365.
A Business Unit is composed of users, teams, and security roles. A user part of a business unit can only be assigned security roles belonging to this business unit.
 
Each Dynamics 365 CRM has a root business unit created by default. It cannot be deleted nor disabled, but it can be renamed. All other business units created by system administrators will be a child of the root business unit.

Business units are useful if the company segregates its business and needs to have different data access for each subsidiary. If there is no need to segregate data between subsidiaries, divisions, or departments then there will only be the one business unit.

Note that two different Business Units don’t have the same Security Roles. On the other side, they can have two different Security Roles, but with the same name!
 

Users

A user has a set of attached privileges at various access levels. Each user can be assigned to multiple security roles. In such a situation and in case of conflict between two security roles, the one with broadest permission “wins”.
Users with security role “System Administrator” or “System Customizer” or another security role with equivalent permissions add and/or remove security roles for all users in the Dynamics 365. Note that when a user is assigned to the global administrator or the service administrator role in the Microsoft Online Services environment, it automatically assigns the user the System Administrator security role in Dynamics 365.
Note that if a user has been assigned to a given Security Role in a TEST environment, it should be assigned again – manually- in a PROD environment: It’s not possible to import security roles assignments via a solution.

To assign a security role to a user, administrators need to go to                 Settings -> System -> Security.

Then click on “User” and select one or multiple users. Then click on “Manage Roles” in the ribbon. 
A pop-up “Manage User Roles” will appear. Security Roles assigned to the user(s) need to be selected.

Team

Dynamics 365 Teams are a collection of users. Those users can be from the same business unit but also for different ones. Users can also belong to multiple teams.
There are two kinds of teams in Dynamics 365:

• Owner Team
  • As for users, security roles can be assigned to owner teams.
  • All users belonging to the team will inherit their security roles.
     
• Access Team
  • Compared to owner teams, access teams do not have security roles and cannot be the owner of records.
  • It simply allows an easier way to share a specific record within a group of users, to give them the ability to work on a certain record (not the entire entity).
  • It can be seen as an upgrade of the simple “Share” privilege. In fact, Access teams have been added to Dynamics 365 to improve the performance compared to the “Share” privilege.
  • For an entity to be shared via Access Teams, it needs to be specifically configured for it. Once this is enabled it cannot be disabled after saving.
    
  • Example: An organization has one Business Unit per continent. Salespersons can only work on opportunities linked to their own BU. But one specific opportunity requires collaboration between salesperson from two different continents. In such a case, an Access Team needs to be created to allows users from different BUs to work on the same opportunity.

Use Owner Teams when the number of teams is known at the design time of Dynamics 365 and when owning records by entities others than users is required by the company’s business policies. 

When the number of teams is not known as design time, when teams are dynamically formed and dissolved or a unique set of users requires access to a single record without having ownership, Access Teams should be used.
 

Hierarchical security

Hierarchical security gives managers the privileges to read, update, append, and append to their subordinates’ records. It’s an addition to the security model in Dynamics 365 and all can be used together at the same time.

Hierarchical security enables easier visibility of subordinates’ activities that can be used in a dashboard and for easy reporting. The feature grants read permissions to managers above the direct manager[2]

Two security models can be used for hierarchies: 

• Manager Hierarchy 
  • Managers must be within the same business unit – or the parent business unit - as the user, they manage.
  • It is based on the “Manager” field in the user entity. Based on this field, there is two types of relations between a manager and their subordinates:
    • Direct report: the manager is the direct manager of the subordinate (e.g: the lookup points to him/her).
    • Non-direct report: the manager is a direct or non-direct reporter of the subordinate’s manager (e.g: the “manager” lookup of the “manager” lookup of the subordinate). 
      There is a “Depth” parameter to set until how far a manager can see the data for the subordinates of his/her subordinates.
  • For non-direct reports, a manager has only Read-only access to the data. For direct report, Read + Write + Update + Append + Append To rights are given to the manager.
     
• Position Hierarchy
  • It enables data access across business units. It’s useful if managers manage people across several business units. For example, in a customer service organization, the managers may need to access services cases handled in different business units.
  • A user doesn’t have to be an actual manager of another user to access the user’s data. When Manager Hierarchy is based on the “Manager” field of the user’s entity, Position Hierarchy is based on the job a user has been tag too.
  • In Dynamics 365, administrators can define various job positions and organize them in the Position Hierarchy. For example, the CEO will be on top, the VPs will be just below and the Managers below VPs.[2]
  • With Position Hierarchy, the direct higher positions have Read + Write + Update + Append + Appen To rights to lower position’s data. Non-direct higher positions have Read-only access.
  • As for Manager Hierarchy, the “Depth” parameter enables to limit the amount of data accessible by higher positions.
  • Note: To add a user to a position, the security privilege “Assign position for a user” must be granted.
    

Hierarchical security does not by-pass security roles. If a manager does not have access to an entity but its subordinates do, hierarchical security will not enable access to the manager. For example, if there is an entity called “Manage Evaluation” used by subordinates to evaluate their managers and the Manager security role has not to access the Read access to this entity, he/she will not be able to see the data.

By default, Hierarchical Security is disabled. Administrators need to enable it. Also, note that System Administrator can exclude given entities from the hierarchy model.
 

Others

Default Security Roles

Out-of-the-box, Dynamics 365 offers multiple pre-defined security roles.

• System Administrator
  • System Administrator is the highest level role which encompasses all the privileges and has over-riding rights. The System Administrator has the authority to allow and remove access to other users and define the extent of their rights. For example, the System Administrator and the System Customizer are given access to custom entities by default while all other users need to be given access. This is the only role that cannot be edited.
• System Customizer
  • The System Customizer role is similar to the System Administrator role which enables non-system administrators to customize Dynamics 365. A Customizer is a user who customizes entities, attributes, and relationships.

If the default security roles don’t match the security level required, system administrators have three possibilities:

• Modify a default security role
• Create a new security role from scratch
• Copy an existing security role as a new one with the “Save As” functionality.

As a rule, security roles should not be created from scratch. The best approach is to take a pre-defined security role, modify it, and save it under a new name. It enables to maintain a certain consistency and avoid mistakes such as forgetting “basics” miscellaneous privileges (e.g: the Read privilege on the entity “Web Resource”).

Be careful when a security role is being renamed. Dynamics 365 doesn’t prevent two security roles to have the same name!

Minimum User

Microsoft offers a solution that contains a Security Role name “min priv apps use”. As the name suggests, this role contains the minimum privilege and access levels required to log in the Dynamics 365. Users assigned only to this security role will not be able to change any record, but they can at least log in.

The solution can be found in Microsoft documentation.
 

Recommendation: It’s considered as a best practice to use the cumulative property of security roles. Each user should be assigned to the “Minimum User Security Role” and then security roles should be added to the users to enable them to work with the data.
In that way, the minimum user security role ensures that users can log in Dynamics and the other security role is only related to entities and task-level privileges.
 

Screenshots

In Dynamics 365, the list of Security Roles is available under the “Security” region of Dynamics 365 configuration panel: Settings -> System -> Security.

A click on the feature “Security Roles” will display the list of all Security Roles, sort by their name in alphabetical order by default.

When clicking on a role, the matrix contains privileges and access levels is displayed. Privileges are grouped under different tabs based on their functionality. These groups include Core Records, Marketing, Sales, Service, Business Management, Service Management, Customization and Custom Entities.

TIP: The access level of all the privileges for a particular entity can be changed at one go by clicking on the row header. Similarly, the access level of a privilege across all entities can be changed in bulk by clicking on the column header.

Field-level Security

In addition to defining security around users and teams, a more minute level regulation of security can be done around a single field. This is achieved with Field Security Profiles.

A field security profile gives access to certain fields that have been enabled for field-level security. It allows users to read and/or update and/or create such fields. Users without access will see the field’s name but not its value – it will be replaced by “****”.

In the Security region of Dynamics 365 configuration, the features “Field Security Profile” will display a list with all profiles. To configure a profile, administrators can:

• Assign Teams or Users to it
• Select the permissions for each field enabled for Field Security. There are three permissions: read, update, and create.

For a field to be eligible to Field-level security, it must be specifically enabled:
 

In a form, fields enabled for Field Security are indicated with a small key after their name.
 

Multiple Field Security Profiles can be created. As for security roles, users and/or teams can be assigned to Field Security Profiles.

Note that System Administrator don’t need to be assigned to a Field Security Profile to see a field – they can do everything!

Some out-of-the-box fields like “Created By” or “Parent Id” cannot be enabled for Field Security.

 

Forms

Security Roles are used to managing access to the data and action that can be taken on it, but it also enables to change of the UI of a form. For example, by offering fewer options to a user, it creates a cleaner UI and the interface is enhanced.
It’s possible to enable access to a given form only for given Security Roles. When customizing a form, the button “Enable Security Roles” allows to select one or multiple Security Roles that will be able to interact with the form. By default, all Security Roles are selected.
 

If a user as access to more than one security role, a drop-down list will let the user choose which form will be displayed. System Administrators can set the orders of the forms when customizing the entity.

As for Forms, Dashboards in Dynamics 365 can also be enabled for only a set of selected Security Roles.

Unique ID

As for all records in Dynamics 365, each Security Role is assigned with a unique identifier and can be accessed through the Web API for example. The GUID can be found in the URL when opening a security role in Dynamics 365.
 

There is also an entity called “Privileges” in Dynamics 365. When an entity is created, there are 8 new “Privileges” records that are created – one per security role privilege. Each of these records has a GUID. When a user encounters an issue related to security roles privileges, the GUID is printed in the error log file.

Security in Microsoft World

Security Roles with privileges and access levels are specific to Dynamics 365. Security in other products of the Microsoft Family is managed differently, with each application having its one way to deal with data security and management.
For example, Sharepoint’s security contains Groups, Sites, and sharing capabilities and PowerBi makes usage of “Row-level security (RLS)”.
When combining such products together, the way to handle data security should be analyzed, defined, and discussed.
 

 

---

[1] When changing the business unit of a user, the associate security roles are removed. The user will not have access to Dynamics until a new role is assigned.

[2] While configuring hierarchical security, the parameter “Hierarchy Depth” controls direct manager’s access to the subordinate’s records of their subordinates. Configuring this depth above 5 can impact negatively the performance of the system. Microsoft recommends keeping the effective hierarchy security to 50 users or less under a manager/position.

[3] This Job Position Hierarchy is also used by the button “View Hierarchy”   in the User entity.