Show custom ribbon button based on Security Role of the logged in User in Dynamics 365 | Ribbon Workbench in XrmToolbox

In ribbon button customization, it is a common scenario to show the button only to a certain set of users who have a certain security role.

Security Role Scenario

  1. Let’s assume Subscription Manager is a security role in your Dynamics 365.

  2. And the Ribbon button will only be visible to the Users who have been assigned this Security Role.

  3. If they have this Role, they’ll be able to see the button as below

  4. And, if the Role is not assigned, the logged In user won’t be able to see the Button.

  5. See below that in this case, the button will not show up.

JavaScript Code to check assigned Security Roles to the logged in User

  1. Since we are going to use a CustomRule further in the Ribbon Workbench to pick a true or false value based on whether the logged in user has a Security Role or not, let’s write a quick JavaScript function to provision the same.

Tip: Make sure you now pass the PrimaryControl (context) to any JS functions and avoid using Xrm.Page since the same has been deprecated.

// JavaScript source code
contactFormCustomization = {
    checkSubscriptionAccess: function (context) {
        "use strict";
        var currentUserRoles = context._globalContext._userSettings.securityRoles;
        var roleId = "BA69EA1F-A76E-EB11-A812-000D3A1948AB"; // Subscription Manager role
        roleId = roleId.toLowerCase();
        // Get all the roles of the Logged in User.
        for (var i = 0; i < currentUserRoles.length; i++) {
            var userRoleId = currentUserRoles[i];
            if (userRoleId == roleId) {
                // Return true if the Role matches
                return true;
        return false;

Refer this post which discusses a simple JavaScript function to use in order to check if the logged in User has a certain security role or not –


  1. Hard-code the GUID of the Security Role which you are looking to check.
  2. Then read all the Security Roles assigned to the user.
  3. Once the Security Roles are found in the logged in User’s Security Role, return true. Else, return false.

Ribbon Button – Enable Rule

Let’s see how the button customization will look like in XrmToolBox’s Ribbon Customization –

  1. In Ribbon Workbench, you need to add a CustomRule under Enable Rules for the Ribbon button.

  2. Then, it asks for the JavaScript function (mention the function which returns a simple true or false based on above steps). and then mention the library –
    Also, pass the context PrimaryControl and using the same, pick the Security Roles of the logged in user as mentioned in the JS code explanation above.
    I’m naming my Enable Rule as SecurityRoleCheck.

    Now, the CustomRule I’ve applied will call the JS function and is expected to receive either a true or a false based on the code. If false – the button will not be enabled, if true – the button will be enabled.

  3. Now, make sure you add this Enable Rule to the Command (which is in-turn attached to the Ribbon Button itself)

Hope this was helpful. Here are some more XrmTool / Ribbon Button customization related posts you might find helpful –

  1. Ribbon button visibility based on a field value in Dynamics 365 | Ribbon Workbench
  2. Get GUID of the current View in Dynamics 365 CRM JS from ribbon button | Ribbon Workbench
  3. Pass Execution Context to JS Script function as a parameter from a Ribbon button in Dynamics 365 | Ribbon Workbench
  4. Pass selected rows’ GUIDs to ribbon button in D365 | Ribbon Workbench
  5. Debug Ribbon button customization using Command Checker in Dynamics 365 CE Unified Interface
  6. Show Ribbon button only on record selection in Dynamics CRM
  7. Hide Custom Ribbon Button [Easy Way] – Ribbon Workbench
  8. Enable Flow button on D365 Ribbon
  9. [SOLVED] Navigating URL from Ribbon’s custom button in Dynamics for Phones app
  10. Fix Ribbon icons on the Unified Interface in D365 CE
  11. Connecting XrmToolBox to an MFA enabled Dynamics 365 environment | Azure AD
  12. Find deprecated JS code used in your Dynamics 365 environment | Dynamics 365 v9 JS Validator tool | XrmToolBox

Thank you!!

D365 PSA: Delegated Resource gets error on making time entries for another Resource

Have you been added as a Delegate for a fellow colleague but not able to Read, Create or Submit Time Entries on their behalf?

Let’s see what you are missing.

Before that, if you want to learn about Delegations in D365 PSA, check this Delegating Time Entries in PSA


William Contoso wants to make Veronica Quek as his Delegate and let her enter time on his behalf. So William created a Delegate record for Veronica.

Error for the Delegate Resource

Now, Veronica is attempting to do time entries for William by going to Time Entry Calendar view and switching the user to William.

  1. And when Veronica wants to enter time as William, she’d switch to the User on the Time Entries Calendar View like this –
  2. But, see this error and she don’t know what the issue might be. Even though she’s the Delegate!

Missing Security Role

Yes, this is the first thing you should check

  1. Veronica Quek is missing a Delegate Security Role in PSA to be able to make time entries on behalf of other users.
    Assign Delegate security role to the user to make them enter time on behalf of others.

Hoping this is quick fix for you. 🙂


Security Roles in CRM

Understanding the Security Model


  • Security model has been defined into the Dynamics CRM that protects data integrity, privacy and provides efficient data access and collaboration.
  • Restricts users from unauthorized access and shows what a particular user must see depending on their roles/privileges.
  • Does not let a user access records not owned by them.
  • Also supports data sharing so that records can be viewed by users though they don’t own it themselves.


Three major areas of security model in CRM are as follows:

  1. Role Based Security
  2. Record Based Security
  3. Field level security


Role Based Security


Role based security defines a set of privileges that can be assigned to a user in a form of a role.

A user must be assigned to at least one such role.

Roles can also be assigned to teams in Dynamics CRM 2013.




MS Dynamics CRM has 14 predefined roles which are defined to match security best-practice of providing only what’s necessary to a particular type of user in the organization.

Custom roles can, however, be created.

Each role is associated with a set of privileges.

One or more roles can be assigned to a user or team.

Creating a new role with intent to assigning a privilege is recommended than modifying an existing role. Roles at user level can’t be modified.



A privilege is a permission to perform an action. There are 580+ privileges predefined during setup. Privileges are built-in to the product.

Privileges cannot be added, modified or deleted. However, new roles can be defined to use the predefined set of privileges.

The platform checks for privileges and rejects any operation on which the required privilege is not found.

Privilege is combined with a depth and access level.


Access Level


Access level defines the depth at which a user can access a particular entity type in the organization.

The access levels defined are as follows:

  1. Global (Organization)

This level gives a user access to all records. User with this level automatically have all the levels Deep, Local and User as well.

  1. Deep (Parent: Child Business Unit)

This access level gives a user access to records in user’s business unit and all business units subordinate to the user’s business unit.

  1. Local (Business Unit)

This access level gives access to records in the user’s business unit. Usually assigned to managers with authority over the business unit.

  1. Basic (User)

This access level gives a user access to records he/she owns, objects that are shared with them and objects that are shared with the team which a user is a member of.

  1. None

No access is provided.


Record Based Security


It is the security provided to individual records. It is provided by using access rights.

Access rights are provided after privileges have taken effect. A user may not be able to access a record even if he/she has access granted but does not have Read privileges on that entity the record is in.


Access Rights           

The access rights provided are as follows:

Read, Write, Assign, Append, Append To, Share, Delete.

Create Access – Create Access in this does not apply to an individual record. It applies to a class of Entities. Create is handled as privilege. A user who creates a record has all the privileges to that record unless any other access right forbids it.

Sharing Records

Sharing lets user give other users/teams access to a specific record. Useful for sharing information with roles that have only Basic access level.

Sharing capabilities provided are as follows:

  1. Share

Sharing a record with another user holds providing access rights to another user for the record which is being shared.

GrantAccessRequest is used to share a record with another user/team. When a record is being shared with a user, indicate what access rights you wish to grant to that user.

Records should be shared with users who have privilege for that particular entity type.


  1. Modify Share

Rights granted to a user after sharing a record can be modified as well. ModifyAccessRequest is used to carry out this task.


  1. Remove Share

If you share a record with another user/team, you can stop sharing the same. RevokeAccessRequest is used to carry out this operation.


Sharing and Inheritance

If a parent record is created, the sharing properties with the parent record is assigned to the child record.

Child record also maintains its own sharing properties.


Assigning Records

Assign Records means handing over the ownership of a record to another user. The original user then loses ownership of that record.

The system administrator can decide whether or not, should the assigned record be shared with its previous owner.

If ShareWithPreviousOwner is selected, then the previous owner has all access rights to the assigned record.


Dependencies between Access Rights

Security dependencies exist between access rights because a user needs more than one access right to access a particular record.

Create – CREATE & READ are required.

Share – SHARE & READ is required.

Assign – ASSIGN, WRITE & READ is required.

Append – READ & APPEND is required.

AppendTo – READ & APPENDTO is required.



Field Level Security

In field level security, access to high-impact business fields is restricted.

For 2013 release of CRM, field security can be applied to custom fields only.


The following steps are carried out to restrict access to a field:

  1. Create a field security profile.
  2. Associate users/ teams with profile.
  3. Add specific field permissions such as Create, Update or Read to the profile.

System Administrator field security profile gives access to all secured fields. This profile is system managed and cannot be deleted or modified.


There are basically 3 restrictions that can be added in Field Security Profiles once created. They are:

  1. Allow Read
    Specifies if users should be able to read information from this field.
  2. Allow Create

Specifies if a user can add information to this field after it has been created.

  1. AllowUpdate

Specifies if a user can edit information from this field.


How secured fields behave for Retrieve and RetrieveMultiple

When Retrieve and RetrieveMultiple are used, CRM check user’s access rights for each record and secured fields. If a user doesn’t have access to secured fields, no exception is thrown but null values are retrieved for secured fields.


If the retrieved data has an access field and user is not impersonated to access it, the user is returned null. A null retrieved by the absence of data and a null retrieved due to lack for privilege can’t be distinguished.


Also, if the secured field is in the filter criteria, a null is substituted for the actual value of the filter criteria.

Following is the justification of how secured fields behave in different scenarios:


  1. Filtered Views
    Filtered view will not return data for secured fields if user is not impersonated with proper access rights to the field.
  2. Records are shared

A user can only give access to another user of the access that they themselves have. The user or team members with whom the record was shared now have that type of secured access field only on the shared secured fields on only that particular record, even if the user to whom it was shared does not have field security profiles that give them access.

  1. Create or Update.

If a user does not have required impersonation on the required secured field while calling Create or Update methods, an exception is thrown.


Hope this was helpful! 🙂