A question was asked on the Microsoft Dynamics 365 Community forums about how to hide or show a workflow action button based on the current user’s role, and since there are a few different ways to do this, I thought it was worthy of a blog post.

What’s an Action Button?

If you’re not familiar with action buttons, they are a pretty powerful feature included in Entity Lists and Entity Forms allowing you to add buttons that perform actions (I know, they are well named!). For example, action buttons allow you to perform actions such as:

• Create a new record
• Download the list of records
• View the details of a particular record
• Edit a particular record
• Delete a record
• Run a workflow on a record
• Create a related record
• Activate a record
• Deactivate a record

Within an Entity List, non-record-specific actions (like download or create) appear above the list, and the record-specific actions (like edit, delete, and run workflow) appear as options in a dropdown in an additional column in the grid. On an Entity Form, you have the choice of adding these buttons above or below the form itself. Of course, the necessary Entity Permissions are required for a user to perform these actions.

The original poster of the question wanted to add a button to an Entity Form that allowed the user to run a workflow on that particular record, but only wanted the button to appear to users with a specific role. I’ll present a few different options here on how that can be achieved.

jQuery/JavaScript and Liquid

If you asked 100 Dynamics 365 Portal developers, my guess is that most would say they’d use JavaScript in this situation. If you’re considering this approach, please be sure to read the “But, If You’re Concerned About Security…” section below!

Since the action buttons are pretty easy to target using jQuery selectors, it’s simple to remove those buttons, using something like:

$(document).ready(function() {
    $('.form-custom-actions .workflow-link[data-workflowid="143052ff-1bf0-4cfc-99cf-c5bd48f58013"]').remove();
});

In the example above, I’m targeting the specific workflow button based on the ID of the workflow. It’s possible you could have multiple workflow buttons that point to different workflows, so that an easy way to distinguish between them. Use your browser developer tools to find the button you’re looking to get rid of to figure out what jQuery selector you need.

So now that we know how to hide them, the other part was to take into consideration the user’s role. You can’t do that in pure jQuery/JavaScript – you need a little bit of Liquid, like so:

{% if user.roles contains 'Administrators' %}
$(document).ready(function() {
    $('.form-custom-actions .workflow-link[data-workflowid="143052ff-1bf0-4cfc-99cf-c5bd48f58013"]').remove();
});
{% endif %}

In this case, we’ve hidden those buttons for anyone with the Administrators web role. Of course, we can easily adjust the logic to hide for anyone that doesn’t have a particular web role (move the JavaScript into an ELSE condition, and leave the IF condition empty).

CSS and Liquid

In the above case, the JavaScript is so simple (using a basic selector to hide an element), we can actually do it in CSS. Just add the following to the Custom CSS attribute on your Web Page (Entity Forms don’t have a Custom CSS attribute):

{% if user.roles contains 'Administrators' %}
.workflow-link[data-workflowid="143052ff-1bf0-4cfc-99cf-c5bd48f58013"] {
  display: none;
}
{% endif %}

But, If You’re Concerned About Security…

The great thing about the above solutions is that they are pretty simple. Just a few lines of code, and you’re done! However, because they rely on JavaScript or CSS, this means you are using client-side technologies, and if you think this is a good technique to deal with situations where users shouldn’t be able to run a workflow (and really bad things happen if they do), see my previous post which has a section on security through obscurity.

So, I personally wouldn’t use the above techniques to hide buttons for security reasons. If you’re hiding buttons because they don’t apply to a particular group of people (but if they did run it, it wouldn’t matter), then the client-side approaches are fine. But, if you’re concerned about security, I’d recommend another approach: using Liquid to create conditional Entity Forms.

Using Liquid to Create Conditional Entity Forms

I actually covered this topic just a few weeks ago, so I’ll just cover this technique at a high level.

Essentially, you setup two different Entity Forms, one that includes the workflow button, and one that doesn’t. Then use Liquid to display the correct Entity Form, based on the user’s role, like so:

{% if user.roles contains 'Administrators' %}
    {% entityform name: 'Entity Form without Button' %}
{% else %}
    {% entityform name: 'Entity Form with Button' %}
{% endif %}

Now, user in the Administrators group never know that the button exists, or the ID of the workflow (which would be useful information if someone wanted to try to spoof a request). Much more secure than just hiding the buttons client-side!

Unfortunately, there is the downside that you now have to manage two different Entity Forms. For complex forms with a lot of Entity Form Metadata, this could be a pain.

Teaser About My Next Post

There’s actually another way to conditional hide or show Action Buttons, using an undocumented attribute that appears on the Action Button configuration called Filter Criteria. It won’t, however, help in this particular case because it doesn’t allow you to take a user’s role into consideration when determining if a button should appear or not. I plan on getting more into this feature in my next post…