Mastering Enable Rules and Display Rules in Dynamics 365 Ribbon Workbench

Introduction

In Microsoft Dynamics 365 (model-driven apps), the Ribbon Workbench (a popular community tool by Scott Durow) is used to customize the command bar (formerly ribbon). A key part of ribbon customization is controlling when a button appears or is active. This is achieved through Display Rules and Enable Rules. In this article, we’ll explain what these rules are, explore typical use cases, review common out-of-the-box (OOB) rule options, and discuss developer pain points, limitations, and best practices (including examples of good and bad implementations). The goal is to equip developers with a clear, practical understanding of using enable and display rules in Ribbon Workbench for Dynamics 365.

Display Rules vs. Enable Rules: What They Are and How They Differ

Display Rules and Enable Rules are configurations that determine the visibility and interactivity of a ribbon button based on certain conditions:

• Display Rules — These rules control whether a button is shown at all on the ribbon/command bar. If a display rule evaluates to false, the button is completely hidden from the UI. Display rules are evaluated server-side (at page load). Historically (in Dynamics CRM 2011/2013’s old ribbon UI), a false display rule would hide the button, whereas a false enable rule would show it greyed-out. In modern Dynamics 365’s unified interface (command bar), both false display rules and false enable rules result in the button being hidden. The key is that display rules run on the server on initial load, so they cannot use form scripts and do not refresh dynamically until the page is reloaded.
• Enable Rules — These rules control whether a button is enabled/disabled (active) when shown. In today’s interface, a disabled state also means the button is hidden (since the command bar doesn’t show inactive buttons). Enable rules are evaluated client-side in the browser, and can be re-evaluated during the session (for example, via script calls to refresh the ribbon). Because they run client-side, enable rules can utilize form context (fields, values, etc.) and even call custom JavaScript functions (via a <CustomRule>) to determine the state. They are ideal for conditions that might change after the form loads (e.g. field values changing or selections on a grid).

Why the distinction matters: Some rule types are only available for one or the other. For example, an EntityPrivilegeRule (checks user security privileges) can only be used as a display rule (server-side), while a CustomRule (calls a JavaScript function) can only be used as an enable rule. Also, because enable rules run on the client, you can trigger them to re-evaluate on demand (using Xrm.Page.ui.refreshRibbon() in the classic API) to dynamically show/hide buttons as data changes. Display rules, on the other hand, are set once on load – if their conditions change, the button won’t show/hide until the page is refreshed. Understanding these differences helps you choose the right rule type for your scenario.

Typical Use Cases for Enable and Display Rules

Developers commonly use display and enable rules to implement business logic for ribbon buttons. Here are typical scenarios:

• Conditional Visibility (Display Rules): You may want a button to only appear for certain users or scenarios. For example, show a “Approve” button only to users with a Manager role or only when a record’s status is “Pending Approval”. In such cases, a display rule tied to a security privilege or record state is used to hide the button for others. Another example: hiding the “Activate” button for records that are already active (so the button is only displayed when the record is in an inactive state).
• Conditional Enablement (Enable Rules): Enable rules are used when the button should be present but only clickable under certain conditions. For instance, enable the “Send Email” button only if an email address field is populated on the form. Or on a grid, enable a “Merge” or “Bulk Delete” button only when at least two records are selected (using a selection count rule). In forms, an enable rule might disable (and thus hide) a “Save” or “Submit” button until required fields are filled out or the record is in a certain state.
• Dynamic Show/Hide During Form Interaction: Because in modern Dynamics 365 a disabled button is effectively hidden, many developers use enable rules (sometimes with custom script logic) to dynamically show or hide buttons in response to form events. For example, a “Complete Task” button that should appear only when a task is not already completed or cancelled. This can be achieved with an enable rule that checks the status value and the form state, and then calling refreshRibbon() in the form’s OnChange event of the status field so the button hides as soon as the status changes. (A pure display rule wouldn’t update until a full refresh, which is why enable rules are preferred for dynamic changes.)
• Context-Specific Commands: Sometimes a button should appear only in specific UI contexts — e.g., only on the main grid and not on sub-grids, or only in the form’s quick action menu. Microsoft provides special rules for these cases (like “ShowOnGrid”, “ShowOnQuickAction” etc.) which developers use to ensure a button appears in the intended places. For instance, you might use ShowOnGrid to hide a button from the form’s command bar but show it on the list view’s command bar.

In summary, use display rules for broad conditions that determine if a button should be present at all (often tied to user permissions or initial record state), and enable rules for more granular conditions especially when they might change during the user’s session (form field changes, selections, etc.). In modern Dynamics 365, either type ultimately hides the button if conditions aren’t met, so the choice often hinges on whether you need dynamic re-evaluation (favor enable rules for that).

Common Out-of-the-Box Rule Options

Dynamics 365 offers many out-of-the-box rule definitions that you can leverage in Ribbon Workbench without writing custom code. Below we list and describe some of the most commonly used OOB display and enable rule types:

Common Display Rule Types

• EntityPrivilegeRule: Checks a user’s privileges (from their security roles) on a given table (entity). You can specify a required privilege (e.g. Write, AppendTo) and a depth (Global, Local, etc.). If the user lacks that privilege, the rule will evaluate to false and the button won’t display. Use case: Only display a button (e.g., “Export Data”) if the user has the privilege to perform that action (like Export to Excel or a specific entity’s Create right).
• FormStateRule: Checks the state of the form (Create, Existing, ReadOnly, etc.). For example, you might hide a button on the Create form but show it on existing records. If configured with State="Create", the rule is true on create-mode forms. Often you’d invert this (using the InvertResult attribute) to hide the button during create. Use case: A “Delete Record” button could have a display rule to hide it on new unsaved records (since you can’t delete something not yet created).
• EntityRule: Evaluates the entity context where the ribbon is shown. This is useful when a command is defined at a higher level (like on all entities or a template) and you want to include or exclude specific entities. Use case: You add a custom “Archive” button to the Account and Contact forms via a generic definition, but use an EntityRule to exclude it from Contacts (so it only actually shows on Account forms).
• ValueRule: Checks the value of a specific field/column on the current record. You provide a field name and value to compare. For example, ValueRule Field="statuscode" Value="Inactive". If the field matches the value, the rule returns true. Note: For display rules, the field being checked must be present on the form (or in the grid view) – otherwise the rule can’t evaluate and will default to false. Use case: Hide a “Close Opportunity” button unless the opportunity’s status is Open.
• MiscellaneousPrivilegeRule: Checks for non-entity privileges such as organization-level actions (e.g., ExportToExcel, MailMerge, GoOffline). Use case: Only show a “Go Offline” or “Export” button if that capability is enabled and the user has rights to it.
• OrganizationSettingRule: Displays the button only if a particular organization-level setting is enabled (e.g., SharePoint integration, or if a fiscal calendar is defined). Useful if a button’s function depends on an org feature.
• HideForTabletExperienceRule: Specifically returns false when the app is being viewed on a tablet/mobile browser. Use case: Hide buttons that aren’t supported or relevant in the mobile interface.
• OrRule (for Display): By default, if you attach multiple display rules to a command, all must be true (logical AND). The <OrRule> wrapper allows you to specify alternative sets of conditions (logical OR). Use case: Show a button if Condition A OR Condition B is met – you would wrap two display rules inside an OrRule.

(There are several other OOB display rules for special conditions — e.g. rules related to Outlook client, form type, etc. — but the above are the ones developers most frequently use.)

Common Enable Rule Types

• SelectionCountRule: Used on grids to enable a button only when a certain number of records are selected. You can specify a minimum and/or maximum selection count. For example, a rule with Minimum=2 ensures the button (like “Merge Records”) is only enabled when at least two records are selected; if fewer are selected, the button will be disabled/hidden.
• FormStateRule: The same idea as in display rules, but used on the client side. Often used to disable a button on create forms. For instance, an enable rule with FormState=Create (and possibly invert the result) can ensure a button is disabled on new records until after save (as shown in the example below).
• ValueRule: Checks a field’s value on the form (or in a selected record in a grid) to decide enablement. For example, enable a “Qualify Lead” button only if leadstatus != Qualified. On forms, remember to include the field on the form for the rule to work. On grids, the field must be in the view’s columns. If the condition to check is more complex (multiple values or calculations), you might use a custom rule instead.
• RecordPrivilegeRule: Checks if the current user has a certain privilege for the specific record (taking into account sharing, owner, etc.). This differs from EntityPrivilegeRule (which is global for the entity). Use case: Enable a “Assign Record” button only if the user has share or assign rights on that particular record (maybe it’s not owned by them but shared, etc.).
• CustomRule: Calls a custom JavaScript function (from a Web Resource) to determine whether to enable the button. The function should return a boolean (or a Promise resolving to boolean in the Unified Interface). This is the most powerful rule type since you can implement any logic, e.g., checking multiple fields, making an asynchronous server call, or checking user roles. Use case: You have a complex scenario — e.g., only enable a “Special Discount” action if the user’s job title is Manager and the account has no overdue invoices — you could write a JS function to perform these checks and return true/false accordingly. Note: Long-running custom rules can degrade performance; if you must do an asynchronous check (like an HTTP request), use the Promise pattern so the UI isn’t blocked. (Unified Interface will wait up to 10 seconds for a Promise rule before assuming false.)
• OrRule (for Enable): Similar to display’s OrRule, this wrapper lets you combine multiple enable conditions with OR logic instead of the default AND. For example, you might enable a button if (Field A has value X OR Field B has value Y) by using two ValueRules inside an OrRule.
• ShowOn Rules: A set of special enable rules that influence where the command appears. These include ShowOnQuickAction, ShowOnGrid, and ShowOnGridAndQuickAction. These are attached as enable rules but effectively act as filters for UI context. For example, adding the ShowOnQuickAction rule ensures the button only shows in the form’s quick action menu (the “…” menu) and not in the main command bar. Using ShowOnGrid will make the button visible only in grid toolbars (and hide on forms). Use case: You have a command that only makes sense in a list view, not on an individual record form — you’d include the ShowOnGrid rule.
• SelectionCountRule (reiterating here as enable rule): Also frequently used in conjunction with other rules. For instance, if a button should only work when one record is selected (but not multiple), you can use a built-in rule like Mscrm.SelectionCountExactlyOne (an OOB rule definition) in the enable rules for that command.

These OOB rules can be configured in Ribbon Workbench by adding a rule (either under the Enable Rules or Display Rules node) and choosing the rule type and parameters. Many default Dynamics 365 buttons come with these rules out-of-the-box (e.g., the Share button has a display rule requiring share privilege, etc.), and you can reuse those definitions or create your own. Reusing rule definitions (via the Rule Definitions area in Ribbon Workbench) is a good practice if the same condition applies to multiple buttons (for example, a single custom enable rule “RecordIsActive” could be referenced by several commands that all should only show for active records).

Common Pain Points and Challenges for Developers

Working with ribbon rules can be tricky for new developers. Here are some common pain points and pitfalls when using Ribbon Workbench for enable/display rules:

• Using the Wrong Rule Type: A frequent source of confusion is choosing display vs. enable incorrectly. For example, trying to use a custom JavaScript check as a display rule (which is not possible — custom script only works in enable rules). Or using a display rule for something that needs to change dynamically (which then doesn’t update until a refresh). This can lead to “why isn’t my button showing/hiding when I expect?” frustration. Tip: Use display rules for static conditions (especially related to security or context at load) and enable rules for dynamic conditions (form field-driven logic). Remember: display = server-side (one-time), enable = client-side (re-evaluated).
• Forgetting to Attach the Rule to the Command: In Ribbon Workbench, after creating a rule definition, you must associate it with the button’s command. A common mistake is defining a beautiful rule but not adding it under the Command’s EnableRules or DisplayRules — result: the rule is never evaluated. This can either make the button always visible or never visible depending on other settings. Always double-check that your command has the intended rules linked to it (Ribbon Workbench shows the Command that a button uses, and you can add multiple rules under it). Similarly, ensure the button is linked to a Command in the first place; a button with no command won’t appear at all.
• Misunderstanding Default vs. InvertResult: Many rule types have a Default attribute (the default boolean value if the condition is not met or not applicable) and an InvertResult flag to flip the true/false output. If these are set incorrectly, your logic may be reversed. For example, a FormStateRule with State=“Create” normally returns true on create forms – if you intend to disable a button on create, you might set Default="false" and InvertResult="true" so that on create forms the rule ultimately evaluates false (disabling the button). It’s easy to mix up these settings, leading to inverted behavior. Tip: If a rule seems backwards (button shows when it should hide), double-check if you accidentally inverted the logic or set an incorrect default.
• Fields Not on the Form (ValueRule Issues): As noted earlier, a ValueRule in a form context only works if that field is present on the form (even if hidden). Developers sometimes try to hide a button based on a field’s value that isn’t displayed on the form, and it fails because the rule always evaluates to default (often false). The fix is to add the field to the form (it can be placed on a hidden section/tab if it shouldn’t be visible to users). Likewise, for grid buttons, the field must be in the view columns. Not knowing this can cause a lot of head-scratching when a seemingly correct ValueRule doesn’t work.
• Cache and Publishing Delays: After deploying ribbon changes, you might not see the effect immediately due to client cache. The browser can cache the ribbon definition, so a new enable/display rule might not take effect until you hard-refresh or clear cache. This can be misleading — you think your rule logic is wrong, when it’s just an old version still in use. Always do a full browser refresh (or use a private window) after publishing Ribbon Workbench changes to ensure you’re testing the latest rules.
• Multiple Rules and Unexpected Logic: When combining multiple rules, remember the default logic is AND (all must pass). If you intended an OR logic but didn’t use an <OrRule>, you’ll find the button only shows when all conditions are true, which might not be what you want. Conversely, stacking multiple rules that overlap can complicate troubleshooting (e.g., a display rule hides the button and an enable rule also toggles it – it might be hard to tell which one is preventing visibility at a given time). As a rule of thumb, keep the rule logic as simple as possible. If you need to combine conditions, consider doing it in one custom enable rule function or use an OrRule for clarity.
• Ribbon Workbench Quirks: Ribbon Workbench (as a third-party tool) is generally reliable, but developers have encountered quirks. For example, if you accidentally copy values to wrong fields (like putting a function name in the library field of an action), it can break the ribbon script loading. Or if you create two enable rules each calling different functions, you might assume both run, but in practice one failing condition will hide the button (since all must be true). There have even been reports that having two separate CustomRule enable checks on one command led to only one being evaluated consistently. The safe approach is usually to consolidate logic into one rule per purpose. Also, always ensure the JavaScript web resources you reference in rules are added to the solution and properly published — if a function isn’t found because the library didn’t load, the rule will treat it as false (and you might see a console error).
• No Direct “Security Role” Rule: A subtle limitation is that there’s no out-of-the-box rule to check for a specific security role by name/ID. You can check privileges (which usually aligns with roles) via EntityPrivilegeRule or MiscellaneousPrivilegeRule, but if you truly need “show this button only for Role X”, you typically must implement a CustomRule (where your JS checks the user’s roles). This is a minor pain point if your scenario is role-specific and not easily mapped to a single privilege.

In short, careful configuration and testing are needed. If your button isn’t showing up when it should, use the built-in Command Checker (available in modern model-driven apps) to see which rule evaluated to false. And use the browser’s developer console for debugging custom enable rules (you can include console.log or debugger in your JavaScript to troubleshoot as Hosk describes). These tools can save you time in identifying which rule or condition is causing an issue.

Limitations of Ribbon Workbench and the Underlying Rule Engine

While powerful, Ribbon Workbench and the Dynamics 365 ribbon rule engine have some limitations to be aware of:

• Static Nature of Display Rules: As noted, display rules are only evaluated on page load. This means they cannot respond to changes in real-time. If you need a button’s visibility to respond to form interactions (without a full reload), a display rule alone won’t suffice — you’d use an enable rule approach. This is essentially a limitation of the platform’s design: server-side rules are not aware of client-side events until postback.
• Single Function per Enable Rule: The rule engine allows only one function call per CustomRule. Ribbon Workbench will only let you specify one function in an enable rule’s configuration. If you attempt to call multiple JavaScript functions for one button by adding multiple enable rules or combining in the XML, you may encounter odd behavior (often only the first function runs). The platform expects one unified boolean result per rule. The workaround is to create one function that encapsulates all needed logic (and returns true/false). This is more of a design constraint than a bug.
• Limited OR Logic without Nested Groups: You can use an OrRule to allow alternative conditions, but you cannot easily create complex combinations of AND/OR without nesting rules in multiple layers. The XML allows some nesting (e.g., an OrRule containing multiple rules, each of which could be a ValueRule or even an And combination by default), but it can get confusing. There’s no support for parentheses or arbitrary logic beyond what nested OrRules can express. If you have very complex logic, again a single CustomRule that handles it in code might be simpler.
• Performance Considerations: The more rules and especially custom script checks you add, the more the client has to evaluate when the ribbon (command bar) refreshes. Generally the performance is fine for a few checks, but keep in mind every time refreshRibbon() is called (or the form state changes), each enable rule’s logic runs. Particularly, avoid long-running synchronous operations in custom rules – they can freeze the UI. The platform now allows asynchronous rules via Promise in Unified Interface to mitigate this, but in legacy web client that isn’t available (and those environments would simply expect a quick boolean return). Additionally, if a Promise-based rule doesn’t resolve within ~10 seconds, it auto-fails (so you can’t have something hang indefinitely). This is a limitation to ensure the ribbon doesn’t stay disabled too long, but it means any server calls in custom rules should be optimized (or called beforehand and cached).
• Ribbon Workbench Specific: Ribbon Workbench itself is not an official Microsoft product (though widely used). One limitation is that it operates on the ribbon Diff XML behind the scenes — if something goes wrong, the error messages might not be very friendly. For example, publishing a malformed rule could result in the solution import failing with a generic error. Also, RW doesn’t have an “undo” beyond discarding changes; you have to be careful with modifications. It’s also geared toward the classic command bar; as Microsoft moves to a new “modern commanding” approach (currently in preview), Ribbon Workbench might not support those new model directly (this is more about future limitation). For now, in classic model-driven apps Ribbon Workbench is extremely useful, but be mindful that it cannot enforce all best practices — it lets you do things that might break the ribbon (e.g., reference a non-existent function). Always test your changes in a sandbox environment.
• No Built-in Role/Team Context in Rules: Aside from privileges, if your button logic depends on something like the user’s business unit, team membership, or other context not covered by OOB rule types, the rule engine has no direct concept of those. You’d have to incorporate that via a custom rule (e.g., have a JS check Xrm.Utility.getGlobalContext().userSettings for team info, etc.). This is a limitation in the sense that OOB rules don’t cover all possible scenarios, but rather the most common platform conditions.
• Subgrid Limitations: A subtle limitation noted in Microsoft documentation is that ValueRule cannot be used as a display rule on subgrid commands in the modern UI — it simply won’t work there. Instead, Microsoft recommends using an enable rule to achieve the hide/show effect for subgrid buttons that depend on record values. So if you’re customizing a subgrid’s add button or command bar, prefer enable rules for any field value checks.

Understanding these limitations helps you plan your customization approach (e.g., when to resort to custom code, how to structure your rules, etc.). Despite these limitations, most typical requirements can be met with the combination of OOB rules and occasional custom enable rules.

Best Practices and Examples (Good vs. Bad)

Finally, let’s highlight some best practices for implementing enable/display rules in Ribbon Workbench, along with examples of good and bad practices:

Good Practices

• Choose the Appropriate Rule Type: Use display rules for initial-load conditions that won’t change (security privileges, form type, etc.), and enable rules for conditions that may change or need client logic. This ensures your button behaves correctly (e.g., using an enable rule with a CustomRule to hide/show based on form input is a good practice, since it can respond to user actions).
• Keep Logic Simple and Consolidated: Aim for one rule (or as few as possible) to cover your scenario. If multiple conditions are needed, consider merging them into one CustomRule function or using an OrRule, rather than stacking many separate rules. For example, Good: one enable rule calls a function IsButtonEnabled() that checks all required conditions and returns a boolean. Bad: two enable rules each calling separate functions for each condition, expecting the system to handle them – this can lead to confusion since both must be true and might not both run as expected. One combined rule is clearer and less error-prone.
• Reuse OOB Rules and Define Reusable Custom Rules: If Dynamics 365 provides an OOB rule that fits your need, use it rather than reinventing the wheel. For example, use the built-in Mscrm.SelectionCountExactlyOne rule ID for a one-record selection requirement, or an OOB privilege rule for common privileges. Likewise, if you create a custom rule (say a JS function to check something), consider making it generic and reuse it for multiple buttons. In Ribbon Workbench you can define a rule once under Rule Definitions and then reference it in multiple Command definitions. This avoids duplication and makes maintenance easier (update in one place).
• Use Meaningful Names and Comments: Name your rules and functions clearly. For instance, name an enable rule definition Account.MustHaveEmailEnabled rather than something vague. While the end user doesn’t see this, future you or other developers will thank you. Also, document complex logic either in code comments (for CustomRule functions) or in an internal documentation, especially if the rule isn’t obvious.
• Attach and Configure Correctly: Ensure that after creating a rule, you attach it to the Command (the link between button and actions) as intended. Double-check the Ribbon Workbench interface: the Command should list all the Display Rules and Enable Rules that apply. This sounds basic, but it’s a step where mistakes happen easily. A good practice is to do a quick test: temporarily set an enable rule’s Default to false (so it hides the button always) to confirm that the rule attachment works (the button disappears), then revert to actual logic.
• Leverage RefreshRibbon for Dynamics: If your enable rule depends on form data that can change (e.g., a checkbox that the user can toggle which should hide/show the button), call the refresh function in the field’s on-change event. For example:

formContext.data.entity.addOnChange("myfield", function() {     formContext.ui.refreshRibbon(); });

• This will prompt the client to re-evaluate enable rules immediately when that field changes. This is a best practice for a responsive UI. (By contrast, without this, the user might have to save or navigate away and back for the button to update.)
• Ensure Required Fields are Present: If using a ValueRule or similar, be sure the field is on the form or view. A good practice is to include any “control” fields (even if hidden) on forms if they are used by ribbon rules — this ensures the rule can evaluate properly.
• Optimize CustomRule Performance: Write efficient JavaScript for enable rules. Return quickly if possible. If you need to query data (e.g., check something via an API call), use the asynchronous Promise approach in Unified Interface. Also handle exceptions in your code — if your function throws an error, the rule will typically be treated as false and the button will hide (and you’ll see an error in the console). Good practice is to wrap logic in try/catch if there’s risk and maybe log errors for debugging.
• Test in a Variety of Conditions: Test the ribbon button with different user roles, record states, form types — whatever conditions you’ve encoded. Use the Command Checker in Power Apps (under Settings > Command Checker) to see a breakdown of rule evaluation if the button is hidden unexpectedly. Thorough testing ensures your rule works in all intended scenarios.

Bad Practices (What to Avoid)

• Using Display Rules for Dynamic Conditions: It’s a bad practice to rely on a display rule to hide/show a button based on form data that can change during editing. For example, hiding a button if a field “Is Approved” is true — if that field starts false and later the user changes it to true, a display rule won’t hide the button at that moment. Instead, do this with an enable rule + refresh logic. Using a display rule in that scenario would lead to inconsistent UX (the button would only update on full refresh).
• Attaching Multiple Conflicting Rules: Adding both display and enable rules to a button without clear need can cause confusion. For instance, having a display rule that hides a button and an enable rule that also might hide it is redundant — one false condition is enough to keep it hidden. If you mix them, you may end up questioning which rule is in effect. It’s usually better to use one type per condition. A known bad practice is creating two separate enable CustomRules for one button (one returns true and another returns false in different scenarios) without combining them — since both must be true, this will never enable the button in the false scenario. Instead, combine into one rule or use OrRule logic explicitly.
• Not Reusing and Copy-Pasting Rules: Duplicating rule logic for multiple buttons (via copy-paste) leads to inconsistency and more work to maintain. It’s better to define it once and reuse. For example, copying the same ValueRule definition into 5 buttons is a bad practice — if the condition needs to change, you’d have to edit 5 places. Instead define it centrally and reference it.
• Heavy Synchronous Processing in Enable Rules: Writing an enable rule that performs a slow operation (like a REST API call synchronously, or iterating over large data without yield) is a bad practice. This can freeze the ribbon or delay button showing. An example of what not to do: making a synchronous XMLHttpRequest in a CustomRule (which would lock up the UI). The better approach is to either preload the needed info (maybe compute it on form load and store in a variable) or use an async pattern. Avoid anything in a ribbon rule that you wouldn’t put in an onChange handler from a performance standpoint.
• Ignoring Error Handling: A bad practice is assuming your CustomRule code will always succeed. If it fails (throws an exception), the platform might treat it as false and hide the button, or it could leave the button in an indeterminate state. Always code defensively. For example, if your code expects a field value but it’s null, handle that case. Not doing so could mean the button unpredictably disappears due to a script error.
• Overusing Ribbon for Complex UI Logic: If you find yourself trying to enforce very complex UI rules via Ribbon Workbench (multiple nested conditions, lots of script), consider if there’s a simpler UX or design. Over-engineering ribbon logic can make maintenance hard. For instance, using the ribbon to show/hide many variations of a button for numerous roles might be better handled by designing separate forms or using business process flows, etc. A convoluted ribbon configuration is a sign to step back and reassess.
• Not Documenting Custom Rules: A minor but important bad practice is failing to document what a custom enable rule does. Six months later, another developer might wonder “What does EnableRule_Custom234 do?”. If you at least add comments in the JavaScript function or a description in the Ribbon Workbench (you can’t add comments in XML easily, but you can use clear naming), it will prevent confusion. Avoid leaving “mystery logic” in the system.

Example — Good vs. Bad Implementation

Consider a scenario: You want a “Complete Event” button on an Event entity form, which should only be active if the event record is already saved and its status is neither Completed nor Canceled.

• Bad Approach: You create a Display Rule that hides the button if status is Completed or Canceled, and an Enable Rule that disables the button if the form is new. This might work initially, but the display rule means once the event is marked Completed and saved, the button might disappear on reload (which is fine) but if status changes back for some reason, it wouldn’t reappear without a refresh. Also having two rules when one could suffice is unnecessary.
• Good Approach: Use a single Enable Rule that incorporates both conditions. For example, add a FormStateRule (State <> Create) and a ValueRule (Status not in Completed/Canceled) both as enable rules on the command. Both must be true to enable the button. Since Dynamics hides disabled buttons, this single enable rule setup will hide the button when either condition isn’t met (new form or already completed) — exactly the desired behavior. The Magnetism Solutions blog shows this approach: one rule for “not on Create” (with invert logic) and one rule for “status not closed” (also inverted). This is easier to maintain and leverages standard rules without any custom code in this case.

In summary, follow the principle of simplicity, clarity, and correctness. Use the out-of-the-box features of Ribbon Workbench and Dynamics 365’s rule engine to your advantage, and only write custom code when necessary. Test thoroughly and be mindful of the user experience (no one likes a button that should be there but isn’t, or vice versa).

Conclusion

Enable Rules and Display Rules are powerful mechanisms for tailoring the Dynamics 365 ribbon (command bar) behavior to business needs. By understanding their differences — display (server-side, initial visibility) vs enable (client-side, dynamic state) — and using the rich set of out-of-the-box rule types, developers can implement a wide range of scenarios with minimal code. Remember to watch out for common pitfalls like misconfigured rules, caching issues, or over-complicating logic. With careful use of Ribbon Workbench and adherence to best practices, you can ensure your custom buttons appear when and where they should, and only enable under the right conditions, leading to a clean and intuitive user experience.

By prioritizing official documentation and insights from the Dynamics community, we can avoid reinventing the wheel and solve problems in proven ways. Ribbon customization might have a learning curve, but once mastered, it becomes an invaluable tool in the Dynamics 365 developer’s arsenal for creating streamlined, role-tailored interfaces.

Sources: This article references official Microsoft Docs for Ribbon rule definitions and respected community sources for practical insights and troubleshooting tips. These provide further details and examples for readers who wish to delve deeper into specific rule types or debugging techniques.