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.

Three places we could put it. Three different cost, latency, and scale profiles. Here is the matrix we now run on every "new operation" request.

The three options

Custom 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.

Custom 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.

Azure Function: fully external .NET function, invoked from Power Automate or direct HTTP. Runs in its own compute, scales separately, has its own pricing.

The three solve overlapping problems. The choice is about latency, cost structure, and who maintains the code.

Decision matrix

DimensionCustom 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)

When each one is correct

Custom 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.

Custom API is correct when:

• The logic is primarily Dataverse queries and writes
• Latency matters (under 500ms per call)
• The caller is inside the Microsoft stack (flow, another plugin, Dynamics app)
• The operation completes in under 2 minutes

Azure Function is correct when:

• The logic calls external services with uncertain latency
• The operation may take longer than 2 minutes
• Durability, retries, or checkpointing matter (durable functions)
• The code needs packages the Dataverse sandbox blocks (file IO, sockets, native dependencies)
• You want the compute cost on a different meter from Dataverse

Cost reality

Custom 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.

Azure 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.

The 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.

Gotchas per option

Custom 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.

Azure 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.

Authentication 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.

The decision we ran last month

Requirement: "Calculate and apply a loyalty rebate on every Order created."

• Reads three tables (Customer, OrderHistory, RebateProgram)
• Writes a calculated value back to the Order
• Must run on every order creation
• Expected volume: 2,000 orders per day, bursty up to 50/minute
• Latency target: under one second on order save

Walking the matrix:

• Latency: sub-second is tight for Azure Function with cold start. Custom API stays in-process.
• External dependencies: none. All Dataverse.
• Long-running: no, under 500ms estimated.
• Cost: Dataverse is already paid for; Azure Function would be cheap but not free.

Custom 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).

A 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.

The rule of thumb

If 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.

If 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.

If you find yourself using custom actions for new work, stop. Custom APIs have everything custom actions did plus a schema and better tooling.