Engineered Code is proud to announce the availability of ecLearn - the Learning Management System built on top of Microsoft Dataverse


Dynamics 365 Portal: Conditional Action Buttons on Entity Forms and Lists

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…

7 responses to “Dynamics 365 Portal: Conditional Action Buttons on Entity Forms and Lists”

  1. […] a follow-up to last week’s post on conditional action buttons, I wanted to dive a bit deeper into a very cool, but completely […]

  2. […] a follow-up to last week’s post on conditional action buttons, I wanted to dive a bit deeper into a very cool, but completely […]

  3. pradeep says:

    I have requirement , where i need to hide close and cancel button for particular users . These two are action button
    I have tried the javscript in the blog , but it is not working for me.

    Can you please suggest

  4. JG says:

    Good read and thank you. Could one setup an action filter to only show button if Status Reason equals ‘Problem Solved’ AND Modified Date is <= 7 Days?

  5. Balakrishnan says:

    Hi Nicholas,

    Thanks a lot for sharing your excellent knowledge. I am looking for some advice on the following scenario.

    We have a web form with a series of steps. In many of these steps we have subgrids. We have JavaScript validation in these webform steps to prevent errors by users. Is there anyway to trigger JavaScript validation based on the subgrid content change (e.g. when a new row in the subgrid is added or deleted). FetchXML does not help since we also need to do JS validation using form data that is not yet saved to CDS. The other option would be to add this validation to the ‘Next’ button, not sure how. i.e. the webform would not go to the next step if certain fields are not filled correctly. If we use conditional step we encounter similar issue as with the Fetch XML.

    Thanks a lot for your help and please do correct in case I have misunderstood something here on the portal functionality.

Leave a Reply

Your email address will not be published. Required fields are marked *


Engineered Code is a web application development firm and Microsoft Partner specializing in web portals backed by Dynamics 365 & Power Platform. Led by a professional engineer, our team of technology experts are based in Regina, Saskatchewan, Canada.