Extend the platform

A developer is building an Azure Function that must process a large batch of Dataverse records, calling an external API for each record. The total operation frequently exceeds 10 minutes and must survive host restarts, track progress across steps, and be triggered on demand from a Power Automate flow. The function currently runs on the Consumption plan and times out. Which approach best meets these requirements?

You are building an Azure Function (running on an App Service plan) that must call the Dataverse Web API to update account records nightly. Security policy prohibits storing any client secrets or certificates in application settings or code. The Function should authenticate to Dataverse using its own identity. Which approach should you implement?

Your Dataverse environment must offload heavy order-processing logic to Azure. When an order record reaches the 'Approved' status, a message should be sent to an Azure resource that reliably queues the work, and an Azure Function must automatically process each message as it arrives without polling or a schedule. You need to choose the trigger type for the Azure Function and the mechanism to deliver Dataverse events to it. Which approach meets these requirements with the least custom code?

You need to build an Azure Function that runs automatically every night at 2:00 AM to archive stale Dataverse records. The function must start on a fixed schedule without any external caller invoking it, and it should be inexpensive to host. Which trigger type should you use for the Azure Function?

You are building a custom API message named contoso_RecalculatePricing that must operate against a single account record. The logic reads and updates fields on that specific account and returns a computed total. You want the message to appear in the Dataverse Web API bound to the account table so callers invoke it as a function/action on a specific account instance. How should you configure the custom API definition?

You are building a reusable Custom API message called 'contoso_RecalculatePricing' in Dataverse. The main operation logic is implemented in a plug-in that must run when any code calls the message through the Organization service or Web API. You define the Custom API record, its request/response parameters, and write the plug-in class. When you register the plug-in through the Plug-in Registration Tool, how should the plug-in step be configured so the logic executes as the main operation of the Custom API?

You are building a custom API message named contoso_RecalculateInventory that performs a sensitive, long batch operation. Business requirements state that only users who hold a specific security privilege should be able to invoke it, and the operation must be callable both from the Web API and from within other plug-ins. When defining the Custom API record in Dataverse, which configuration correctly enforces the privilege requirement without writing extra authorization code?

You are building a custom connector for an internal REST API that expects each request to include a static API key in an HTTP header named 'X-Company-Key'. The key is issued per-user and must be entered by each maker when they create a connection. You want the connector to prompt users for the key at connection time and automatically attach it to every outbound request. Which authentication type should you configure on the custom connector?

Your team maintains a REST API whose OpenAPI (Swagger 2.0) definition is stored and versioned in a GitHub repository. You need to create a Power Platform custom connector that stays aligned with the API contract, and you want to minimize manual re-entry of endpoints and schemas whenever the API changes. Which approach should you use when initially building the connector?

Your organization exposes several REST endpoints through an existing Azure API Management (APIM) instance. Each API in APIM already has a published OpenAPI definition and defined security policies. You need to create a Power Platform custom connector that reuses these APIM APIs with the least manual configuration and keeps the connector aligned with the APIM-managed endpoints. What should you do?

You are building a custom connector that calls an Azure Function protected by Microsoft Entra ID. The connector must let makers sign in with their own credentials so the Function receives an access token that identifies the calling user. In the custom connector's security configuration, which authentication type and setting must you configure to obtain a user-delegated token for the Function's app registration?

Your company uses a third-party SaaS expense system that exposes a REST API secured with OAuth 2.0. Users must sign in with their own SaaS account so that the API returns only their personal expense data. You are building a custom connector in Power Platform to let makers call this API from cloud flows on behalf of the signed-in user. Which authentication type should you configure for the custom connector?

You are building a custom connector from a manually authored OpenAPI 2.0 definition for a REST API. One GET operation accepts a repeated query parameter named 'status' that can appear multiple times in the URL (for example, ?status=open&status=pending) to filter by several statuses in a single call. How should you define this parameter in the OpenAPI definition so the connector generates the correct request?

You are building a custom connector for an internal REST API that returns product inventory data. During testing, the flow that consumes your connector cannot reference individual fields (such as 'sku' and 'quantity') in the dynamic content picker — the entire response appears only as a single 'Body' output. You need makers to select individual fields when they use the connector action in a cloud flow. What should you do in the connector definition?

You built an Azure Function App that exposes several HTTP-triggered endpoints returning JSON. You need to make these operations available as actions inside Power Automate cloud flows with the least manual effort, while automatically generating accurate action metadata (operation IDs, parameters, and response schemas). What should you do first when creating the custom connector?

You are building a custom connector for an internal REST API. The backend requires every request to include a static HTTP header 'x-api-version: 2.0'. You want to add this header to all operations without modifying the underlying API or requiring the flow maker to supply the value. What is the most appropriate way to configure the custom connector?

You are building a custom connector for an internal REST API. The API expects a flat JSON payload with fields like customerName and orderTotal at the root level. However, your Power Automate makers want to work with a nested object model where these fields appear under a 'customer' and 'order' object respectively. You need the connector to accept the maker-friendly nested schema in Power Automate but send the flattened structure the backend API requires, without modifying the backend API or writing external code. What should you do?

Your organization uses a custom order-management model-driven app. When an order reaches the 'Shipped' status, several downstream systems (a warehouse system, a customer notification service, and an analytics pipeline) need to react. These subscribers are added and removed frequently, and the developers do not want to modify or redeploy Dataverse code each time a new subscriber is introduced. You want to publish a well-defined, discoverable event from Dataverse that any authorized consumer can subscribe to independently. Which approach should you implement?

You are building an integration that must create an Account record and three related Contact records in a single Dataverse Web API call. If any one of the operations fails, none of the records should be persisted. Which Web API technique should you use to guarantee this behavior?

You are building a nightly integration that must upsert approximately 8,000 account records into Dataverse from an external system using the Dataverse Web API. Early tests using one HTTP request per record are exceeding the maintenance window and triggering service protection API limits. You need to reduce the number of round trips while still allowing each individual upsert to be processed and to receive per-record results. Which approach should you use?