{"slug": "custom-api-vs-custom-action-vs-azure-function-dataverse-decision", "title": "Custom API vs Custom Action vs Azure Function: Dataverse decision", "summary": "Here is a factual summary of the article:\n\nThe article compares three methods for implementing business logic in Microsoft Dataverse—Custom Actions (legacy), Custom APIs (modern), and Azure Functions—focusing on their latency, cost, concurrency, and maintenance profiles. Custom APIs are recommended for most new Dataverse-heavy operations due to their low latency, inclusion in existing licensing, and first-class integration with Power Automate, while Azure Functions are better suited for long-running or external-dependency-heavy work despite higher latency and separate compute costs. The author provides a decision matrix and practical guidance, including a case study where a Custom API was chosen over Azure Functions for a loyalty rebate calculation triggered on order creation.", "body_md": "A client needs to expose a \"calculate the loyalty rebate for this customer\" operation. It reads three Dataverse tables, applies some business rules, writes a result. Every consumer - the Dynamics web app, a Power Automate flow, an external integration - should call the same operation.\nThree places we could put it. Three different cost, latency, and scale profiles. Here is the matrix we now run on every \"new operation\" request.\nCustom Action (legacy): a process defined in Dataverse that can be invoked through the SDK. Steps are Workflow Activity Actions. Old-school but still widely deployed.\nCustom API (modern): the successor to custom actions. Defined as Dataverse entity rows (customapi, customapiRequestParameter, customapiResponseProperty), backed by a plugin that implements the logic. Exposed through the Web API with a typed OpenAPI schema.\nAzure Function: fully external .NET function, invoked from Power Automate or direct HTTP. Runs in its own compute, scales separately, has its own pricing.\nThe three solve overlapping problems. The choice is about latency, cost structure, and who maintains the code.\nDimensionCustom ActionCustom APIAzure FunctionLatencyLow (in-process)Low (in-process)Medium (cross-service)Concurrency limitDataverse'sDataverse'sFunction App'sTimeout2 minutes2 minutes10 minutes (Consumption), configurable higherCostIncluded in DataverseIncluded in DataversePer-execution + computeLong-running workNoNoYes (durable functions)External dependency callsLimited (sandbox)Limited (sandbox)Full flexibilityOpenAPI schemaNoYesManualInvocable from flowYesYes (first-class)Yes (HTTP connector)Maintenance.NET + Workflow.NET.NET (preferred)\nCustom Action is correct when you are maintaining an existing system that already uses them. For new work, skip them - custom APIs are the modern equivalent with better tooling.\nCustom API is correct when:\nAzure Function is correct when:\nCustom APIs consume Dataverse capacity. A high-volume custom API (tens of thousands of calls per day) is paid for by your existing Dataverse licensing - no incremental per-call charge.\nAzure Functions on Consumption plan: $0.000016 per GB-second and $0.20 per million executions. A typical custom function costing 128MB for 300ms runs at roughly $0.00000006 per call. A million calls per month is around $0.25 in compute plus $0.20 in executions - effectively free.\nThe cost math usually favors custom API for Dataverse-heavy work and Azure Function for external-dependency-heavy work. Mixing the two via a custom API that calls a function (rare pattern) pays both bills.\nCustom API gotcha: the plugin that implements a custom API registers against a synthetic \"Custom API message\" step. Debugging is via plugin trace logs, same as any plugin. Deployment is through the solution. OpenAPI schema is auto-generated from the custom api row definitions - mis-typing a parameter name once in Dataverse and once in the plugin code produces a runtime failure that the solution checker does not catch.\nAzure Function gotcha: cold start on Consumption plan can add 2-5 seconds for the first call after idle. For a user-facing interactive call, this is unacceptable. Options: Premium plan (always warm, higher baseline cost), Dedicated App Service plan, or accept the cold-start delay if the call is async.\nAuthentication gotcha for Azure Function: calling Dataverse from an Azure Function requires auth. The cleanest pattern is a managed identity on the Function App with an application user in Dataverse. Tutorials that use a user's personal credentials in app settings are security incidents waiting to happen.\nRequirement: \"Calculate and apply a loyalty rebate on every Order created.\"\nWalking the matrix:\nCustom API won clearly. Implementation was a plugin registered against a custom API definition, called from both a post-operation plugin on Order Create (synchronous, blocks save) and directly from a Power Automate flow (for retroactive recalculation).\nA year later, the client wanted to integrate with an external tax service that takes 3-4 seconds per call. We did not put that in the same custom API - the 2-minute timeout plus the unpredictability of the external service made it fragile. We built a separate Azure Function for the tax call, invoked async from a Power Automate flow. Two tools for two different latency profiles, as it should be.\nIf the operation stays inside Dataverse, start with a custom API. You get latency, integrated ALM, and zero incremental cost. You can always move it to an Azure Function later if the requirements shift.\nIf the operation has any external dependency with unpredictable behavior, start with an Azure Function. You get the durability patterns and the 10-minute timeout that the Dataverse sandbox cannot give.\nIf you find yourself using custom actions for new work, stop. Custom APIs have everything custom actions did plus a schema and better tooling.", "url": "https://wpnews.pro/news/custom-api-vs-custom-action-vs-azure-function-dataverse-decision", "canonical_source": "https://dev.to/sapotacorp/custom-api-vs-custom-action-vs-azure-function-dataverse-decision-2lo4", "published_at": "2026-05-24 02:52:09+00:00", "updated_at": "2026-05-24 03:02:22.407304+00:00", "lang": "en", "topics": ["developer-tools", "cloud-computing", "enterprise-software"], "entities": ["Dataverse", "Power Automate", "Azure Function", "Dynamics", "Custom API", "Custom Action", "OpenAPI", ".NET"], "alternates": {"html": "https://wpnews.pro/news/custom-api-vs-custom-action-vs-azure-function-dataverse-decision", "markdown": "https://wpnews.pro/news/custom-api-vs-custom-action-vs-azure-function-dataverse-decision.md", "text": "https://wpnews.pro/news/custom-api-vs-custom-action-vs-azure-function-dataverse-decision.txt", "jsonld": "https://wpnews.pro/news/custom-api-vs-custom-action-vs-azure-function-dataverse-decision.jsonld"}}