Study guide
4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript
Microsoft Power Platform Developer Associate PL-400
Track your progress as you read
Finished sections get a check mark.
1 Introduction, Exam Overview & Developer Toolchain
0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow
2 Create a Technical Design
1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations
3 Build Power Platform Solutions
2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools
4 Implement Power Apps Improvements
3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance
5 Extend the User Experience
4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component
6 Extend the Platform: Dataverse Plug-ins & Custom APIs
5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events
7 Extend the Platform: Custom Connectors
6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation
8 Extend the Platform: Platform APIs & Azure Functions
7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities
9 Extend the Platform: Power Automate Cloud Flows
8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals
10 Develop Integrations
9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message
11 Exam Readiness & Practice
10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan
4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript
Key Takeaways Explain This Topic AI
Xrm.WebApi (createRecord, retrieveMultipleRecords, execute, etc.) always hits the server and reflects only saved data, unlike formContext which reflects unsaved, in-memory form state.
retrieveMultipleRecords() accepts standard OData query options ($select, $filter, $expand, $orderby, $top) as a single query string.
The command designer's Run JavaScript action mirrors form-event registration (library + namespaced function); Run Power Fx stores an inline formula instead, avoiding a separate web resource.
Visibility and enable rules can be authored as Power Fx expressions in the designer or as classic <EnableRule>/<DisplayRule> ribbon XML for scenarios the designer doesn't cover.
Command bar customizations are scoped independently to a table's main grid, a subgrid, or a form's command bar — a change at one scope does not cascade to the others.
Last updated: July 2026
Two Extend-the-UX capabilities pair naturally: calling the Dataverse Web API from inside client scripts, and configuring the buttons that trigger scripts — or increasingly, formulas — in the modern command bar.
Xrm.WebApi: Client Scripting Against the Dataverse Web API
Xrm.WebApi (used as Xrm.WebApi.online when you need to be explicit about the connected, non-offline case) exposes the same CRUD-plus-actions surface as the Dataverse Web API, but from inside form or ribbon JavaScript: createRecord() , updateRecord() , deleteRecord() , retrieveRecord() , retrieveMultipleRecords() , and execute() / executeMultiple() for custom actions, functions, and custom APIs. Every method returns a promise , so modern code typically uses async / await : async function loadRelatedContacts(formContext) {
- const accountId = formContext.data.entity.getId().replace(/[{}]/g, "");
- try {
- const result = await Xrm.WebApi.retrieveMultipleRecords(
- "contact",
- `?$select=fullname,emailaddress1&$filter=_parentcustomerid_value eq ${accountId}&$top=5`
- );
- return result.entities;
- } catch (error) {
- console.error(error.message);
- }
- }
retrieveMultipleRecords() takes OData query options — $select , $filter , $expand , $orderby , $top — as a single string, mirroring the raw Web API syntax the platform APIs domain covers in more depth. Custom APIs and actions are invoked through execute() with a request object that implements a getMetadata() method describing its operation name, parameter types, and whether it binds to an entity.
The essential distinction PL-400 tests here is network round trip versus in-memory state : Xrm.WebApi calls always hit the server and reflect only what has already been saved to Dataverse, while formContext.getAttribute().getValue() reads whatever is currently in the browser, including unsaved edits the user hasn't committed yet. A script that needs the user's current, unsaved input must read it from formContext ; a script that needs related records from other tables must go through Xrm.WebApi .
The Modern Command Bar and the Command Designer
Microsoft has moved command-bar customization from hand-edited ribbon XML toward the command designer , a low-code, per-table or per-app editor that produces a JSON-based command schema. For most day-to-day button customizations, this replaces manually authoring RibbonDiffXml ; the classic ribbon workbench approach still exists and remains necessary for advanced scenarios — such as certain split-button or flyout structures — that the designer doesn't yet cover.
In the command designer, each command (button) is bound to an action , and PL-400 expects you to know the two script-relevant options:
Run JavaScript — behaves like form event registration: pick a library web resource, a namespaced function, and optionally map parameters (including the primary control, selected record references, or static values) into the function's arguments.
Run Power Fx — write the button's logic directly as a Power Fx formula, the same language used in canvas apps, without deploying a separate JavaScript web resource. Common formulas call Notify() to show a message, Navigate() to open another screen or page, Set() to manage variables, or Patch() to write data directly to Dataverse.
Visibility and Enable Rules
Whether a command shows at all, and whether it's clickable, is controlled by visibility rules and enable rules . The command designer supports Power Fx boolean expressions evaluated against the ribbon's implicit context — for example, an expression referencing whether a record is selected — for straightforward show/hide logic authored without leaving the designer. Scenarios that predate the designer, or that need logic the expression language doesn't support, fall back to classic <EnableRule> and <DisplayRule> definitions in ribbon XML, which reference a custom JavaScript function returning a boolean.
Scope: Grid, Subgrid, and Form
Command bar customizations apply at different scopes — a table's main grid, a subgrid embedded on a form, and a form's own command bar — and each scope is customized independently, whether through the designer or classic ribbon XML with an explicit ribbon location. A common exam pattern presents a requirement ("hide this button only on the account subgrid inside opportunity forms, not on the main account grid") and expects you to recognize that the customization must target the subgrid scope specifically, not the table's grid-level command bar, because a scope-level change does not automatically cascade to every place the table's records are displayed.
Error Handling and Related-Record Retrieval
Because Xrm.WebApi calls are asynchronous network requests, production-quality scripts wrap them in try / catch around the await , or attach a .catch() handler to the returned promise, rather than letting a failed request silently do nothing. A failed request typically resolves to a rejected promise carrying an error.message describing the Dataverse error, which should surface to the user through a form notification rather than only a browser console log the user will never see.
retrieveMultipleRecords() and retrieveRecord() also support $expand , which pulls related records in the same round trip instead of issuing a second call — for example, expanding an account's primary contact alongside the account itself avoids a follow-up retrieveRecord() call purely to read the contact's email address. Favoring $expand over sequential calls matters for the "Optimize and troubleshoot apps" domain's performance concerns, since each additional round trip adds latency the user directly experiences while a form or command is running.