Security Role based Buttons – Missing Key Feature?

Picture this: You’re crafting a robust sales strategy, powered by Dynamics 365. As part of the design, you introduce an approval button for sales exceeding €10,000—a key feature meant for Managers. Creating an enabled rule to detect high-value sales? Easy. A simple ValueRule gets the job done.

But then comes the twist: how do you restrict access to this button so only Managers can actually see or use it?

Sure, there are a few ways to tackle this – but in this article, I’ll focus on one powerful approach: leveraging Security Roles within Dynamics 365 to control button visibility based on user roles.

Dynamics 365 Is Missing a Fundamental CRM Feature

Let’s be real – Dynamics 365 lacks native, out-of-the-box features – something you’d expect from a mature CRM platform – in this case the restrict button visibility based on security roles feature. Sure, most of those gaps can be patched with creative workarounds (some of them, let’s admit, wildly unconventional). But even with all my love for Dynamics and the Power Platform, there’s one glaring omission that stands out: there’s no native way to restrict button visibility based on specific security roles.

Honestly, I could write a whole column on how Microsoft really missed the mark here. Sometimes, I wonder if they’re even using their own product—because the stuff they’ve built in is wild. You stumble across these clunky workarounds and wonder, “Did anyone test this in real life?” It’s probably too much to unpack in this post… but maybe that rant deserves a full page of its own.

So what did I do when faced with this architectural blind spot?

I rolled up my sleeves and did what any seasoned Power Platform wrangler would do: I built my own fix. Because when Microsoft leaves the door locked, you don’t wait for a key – you break in through the window.

My solution? I injected a custom JavaScript into the enable rule of the button itself. No native support, no out-of-the-box magic—just old-school ingenuity. It’s the kind of workaround that shouldn’t be necessary in 2025, yet here we are. I coded a rule to check a user’s security role before the button even dares to show its face. If you don’t belong in the club, you don’t get in. Period.

And yeah – it works. Is it elegant? Not quite. Is it reliable? You bet. But let’s be honest, it feels like patching potholes on a highway that should have been resurfaced a decade ago.

Maybe someday Microsoft will wake up and build in the feature we all assumed already existed. Until then, I’ll keep duct-taping the platform together with JavaScript, caffeine, and sheer willpower. And hey – if you’re tired of duct-taping it alone, I’ve got the code, the coffee, and the know-how. Let me teach you how to tame this beast – because once you crack it, the possibilities are limitless.

And now I will present you the glue that holds my idea together:

function SecurityRoleBasedButton(securityrole) {
    const roles = Xrm.Utility.getGlobalContext().userSettings.roles;
    const targetRole = securityrole.toLowerCase();

    let hasRole = false;

    roles.getAll().forEach(function (role) {
        if (role.name && role.name.toLowerCase() === targetRole) {
            hasRole = true;
        }
    });

    return hasRole;
}

This JavaScript function, SecurityRoleBasedButton, is designed to control button visibility based on user security roles in Dynamics 365. It takes a role name as input, retrieves the current user’s assigned roles via the global context, and checks if any of those roles match the target role (case-insensitive). If a match is found, the function returns true, allowing the button to be enabled; otherwise, it returns false, keeping the button hidden.

Implement it!

To implement it do the following steps:

1. Upload the Web Resource
   • Go to your solution in Power Platform.
   • Add a new JavaScript web resource containing your SecurityRoleBasedButton function.
   • Give it a clear name like SecurityRoleBasedButton.js and publish it.
2. Use Ribbon Workbench ( skip the built-in designer—it won’t work for this)
   • Open the Ribbon Workbench for your solution.
   • Load the entity where the button lives (or create the button from scratch).
3. Locate or Create the Button
   • Select an existing command or add your new button to the desired location on the command bar.
4. Add an Enable Rule
   • In the button’s command definition, add an EnableRule.
   • Choose CustomRule instead of predefined rules.
5. Configure the Custom Rule
   • Reference your uploaded JavaScript web resource.
   • In the rule, set the function name: SecurityRoleBasedButton.
   • Add a parameter of type String – this will be the name of the security role you’re checking against.
   • Example value: "Sales Manager" or whatever role you want the button to be visible for.
6. Publish Everything
   • Commit and publish your changes.
   • Refresh your app and test role-specific visibility.

So there you have it – the workaround that Microsoft forgot to ship. While Dynamics 365 may leave us chasing features with duct tape and JavaScript, the Power Platform community continues to shine through ingenuity, grit, and just a touch of caffeine-fueled rebellion.

This solution isn’t just a fix – it’s a reminder that where the platform falls short, creators like you step up. Whether you’re a seasoned dev or just getting your hands dirty, there’s always room to push the boundaries and build what Microsoft hasn’t (yet).

And hey, if you’re tired of patching things alone, you’re not. I’ve built it, tested it, lived it – and I’m here to show you how.

This article was written with the help of AI to avoid grammar or spelling errors.