Adding a custom button to a model-driven form's command bar used to be a single-tool problem. Ribbon Workbench (a community XrmToolBox tool) was the answer for years. Microsoft then shipped Command Designer as the modern first-party replacement. For a while the two coexisted uneasily; the choice was political more than technical.
As of 2026, Command Designer has matured enough that it is the right first choice for new work, with specific exceptions. Here is the current comparison, and the migration pattern when you inherit a project with Ribbon Workbench customizations.
The current state
Command Designer (Power Apps maker portal):
- First-party, UI-based, no additional tool installation
- Uses Power Fx for command logic (visibility, action, label)
- Ships in the solution as commandDefinition entries
- Works with the "modern" command bar (the one on new model-driven apps)
- Does not work with the classic command bar
Ribbon Workbench (XrmToolBox community tool):
- Third-party, XML-based, requires installing XrmToolBox
- Uses JavaScript for command logic
- Ships as custom RibbonDiffXml in solution XML
- Works with both classic and modern command bars (but modern support is limited for newer features)
What Command Designer is good at
- Simple conditional visibility: "show this button if the record status is Draft" is a one-line Power Fx expression.
- Direct calls to Power Fx patchable operations: Update a field, launch a Canvas dialog, navigate to a record. No JavaScript glue needed.
- Source control friendliness: commandDefinition entries are structured XML in the solution; the diff is readable.
- New-team-member onboarding: makers who know Power Fx can author commands without learning JavaScript and the classic ribbon XML schema.
What Ribbon Workbench still wins at
- Complex conditional logic: visibility rules involving multiple fields, related record values, or security role checks are easier in JavaScript than in Power Fx.
- Integration with existing JavaScript: if your project has a form script library with utility functions, commands can call into it directly.
- Mature patterns for classic apps: if you maintain a classic app (Unified Interface but pre-modern command bar), Ribbon Workbench is the only practical tool.
- Fine control over ribbon structure: hiding out-of-box buttons, repositioning, custom groups - Ribbon Workbench's XML editor exposes the whole surface.
Our decision rule
For new model-driven apps on the modern command bar: start with Command Designer. Use Power Fx for command logic. Only fall back to Ribbon Workbench if you hit a feature gap.
For existing apps on the classic command bar: stay with Ribbon Workbench until the app is migrated to modern. Mixing the two tools on the same app creates confusion.
For apps that explicitly need JavaScript logic: Ribbon Workbench if the logic is complex; Command Designer with a minimal JavaScript bridge if the logic is small.
Migration pattern: Ribbon Workbench to Command Designer
Projects inherit Ribbon Workbench commands that were authored years ago. Moving them to Command Designer is usually worth it when:
- You are upgrading the app to the modern command bar
- You are simplifying the team's skill requirements (one tool, one language)
- The existing commands are maintenance burden (JavaScript with no tests, cryptic logic)
The migration is per-command, not all-or-nothing. Our process:
Step 1: inventory the existing commands. Export the solution, parse the RibbonDiffXml to list every custom command with its logic.
Step 2: rebuild each in Command Designer. Create the equivalent command in the maker portal. Power Fx the visibility and action logic. Test on a form.
Step 3: remove the Ribbon Workbench definition for that command. Edit the RibbonDiffXml to remove the old entry. Re-export the solution.
Step 4: deploy both changes together. The deploy adds the Command Designer command and removes the Ribbon Workbench command atomically.
Steps 2-4 per command. For a project with 15 custom commands, budget a day per complex command, a couple hours for simple ones. Four or five working days total.
What breaks in migration
JavaScript that called utility libraries. Commands that invoked shared JavaScript functions from the form library don't translate directly to Power Fx. Two paths:
- Rewrite the utility in Power Fx (if it's simple enough).
- Keep a small JavaScript bridge: the Command Designer command calls a Power Fx function, which calls into the JavaScript library via the Launch() function's custom connector or a custom API endpoint.
Path 2 sounds hacky but works. For utility logic that is genuinely shared across forms (e.g., "format phone number by country"), keeping the JavaScript and bridging is simpler than rewriting.
Conditional visibility based on related records. "Show this button if the account's parent has status X" requires a lookup from the current record to its parent, then a field check. In JavaScript this is a Xrm.WebApi call; in Power Fx it is a LookUp that may or may not delegate.
For simple parent checks, Power Fx works. For complex graph traversals, either denormalize the needed field onto the current table (via a rollup or plugin) or keep the command in Ribbon Workbench.
Button placement customization. Ribbon Workbench lets you specify exact positioning: "place this button to the left of Save, in the Actions group." Command Designer's placement controls are more limited - you pick a group, not an exact slot. If pixel-perfect placement matters, Ribbon Workbench retains an edge.
The one gotcha: solutions and ownership
Command Designer commands ship in the solution via new commandDefinition and commandComponent entities. Ribbon Workbench customizations ship via ribbon XML on the entity or application.
When both tools have touched the same entity's ribbon, solution imports can get confused. The safe pattern:
- One tool per entity's ribbon at a time. If migrating, finish the entity before moving on.
- Keep managed-solution layering in mind. A Ribbon Workbench customization from an older managed layer plus a Command Designer customization from the current solution can produce unpredictable behavior at runtime.
The one-year outlook
Microsoft's direction is toward Command Designer as the canonical tool. New command-related features (command bar on Canvas components, AI-assisted command generation) are shipping to Command Designer first.
Ribbon Workbench will remain supported for the foreseeable future as long as classic command bar exists, but the feature gap is widening. For any project with a five-year horizon, investing in Command Designer skills over Ribbon Workbench is the right bet.
If you have a Ribbon Workbench-heavy codebase, start migrating the commands you touch anyway on feature work. Don't do a big-bang migration unless you are already upgrading the app for other reasons. Incremental migration is the path that has worked across three projects we have moved.
