7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads

Not every piece of custom logic belongs inside a Dataverse plug-in. PL-400 expects developers to recognize when a workload has outgrown the plug-in sandbox and should be offloaded to Azure Functions instead, and to choose the right trigger type once it is there.

Why Plug-ins Have a Ceiling

Dataverse plug-ins execute inside a sandboxed, multi-tenant environment that enforces strict resource limits to protect the shared platform. The limit that matters most for this decision: a synchronous plug-in step has a two-minute execution time limit. Asynchronous plug-in steps get more headroom because they run as background system jobs rather than blocking the triggering operation, but they are still subject to sandbox constraints and are not designed for open-ended, long-running, or highly compute-intensive processing.

A plug-in is the right tool when logic is: tightly coupled to a specific Dataverse event, fast (well under the two-minute ceiling), and primarily about validating or shaping data as part of that transaction. An Azure Function is the right tool when logic is: long-running (minutes to hours), scheduled independent of any Dataverse event, dependent on calling multiple external systems, or compute-heavy (image processing, document generation, complex calculations, machine learning inference).

Patterns for Offloading Work

The typical integration pattern keeps the plug-in thin and pushes heavy lifting to Azure:

• A lightweight synchronous plug-in validates input and, if valid, quickly calls out — either directly to an Azure Function's HTTP endpoint (a webhook-style call), or by dropping a message onto an Azure Service Bus queue/topic for the Function to pick up asynchronously.
• An asynchronous plug-in or a business event registration publishes the event without blocking the user, and an Azure Function subscribed to that channel performs the actual long-running work — completely decoupling the user's save operation from however long the downstream processing takes.
• For genuinely long multi-step processes (e.g., a workflow that waits on multiple external systems across minutes or hours), Durable Functions provide an orchestration pattern that can pause and resume without holding a synchronous connection open the whole time.

Choosing an Azure Functions Trigger

Azure Functions supports many trigger types; three come up repeatedly in Power Platform integration scenarios:

A scheduled nightly job with no manual trigger is a Timer trigger by definition — reaching for an HTTP trigger there would require something else to call it on a schedule, which is exactly what the Timer trigger already does natively via its NCRONTAB expression.

Why This Distinction Is Exam-Relevant

Scenario questions on this topic typically describe a symptom — a plug-in timing out, a process that needs to run outside business hours, or logic that calls three different external APIs and aggregates the results — and ask where that logic belongs. The correct answer hinges on matching the execution characteristics of the workload (duration, whether it is event-driven or scheduled, and its dependency footprint) to the platform component built for that shape of work, rather than defaulting to "add more code to the existing plug-in." Recognizing the two-minute synchronous plug-in ceiling as the trigger for this decision, and then picking the matching Azure Functions trigger type, is the core skill being tested.

Hosting Plan Affects the Function's Own Time Budget

Once logic has moved to an Azure Function, its own maximum run time still depends on which Azure hosting plan it runs on:

• Consumption plan — the default functionTimeout is 5 minutes, and it can be configured up to a 10-minute maximum. This plan scales automatically and is billed per execution, but it is not the right choice for a workload that might legitimately run past 10 minutes.
• Premium plan — supports a much longer configurable timeout and keeps instances "warm," avoiding cold-start delay, which matters for latency-sensitive webhook-style calls from a plug-in.
• Dedicated (App Service) plan — runs on provisioned VMs the developer already controls, effectively removing the platform-imposed timeout, appropriate for the longest or most resource-intensive orchestration work.

A workload that clearly exceeds the two-minute plug-in ceiling but is still fairly short (a few minutes) fits comfortably on a Consumption plan Function; a workload that could run for tens of minutes or longer needs a Premium or Dedicated plan, or a Durable Functions orchestration that can checkpoint and resume rather than holding one execution open indefinitely.

Keeping the Plug-in Call Itself Fast

Even when a plug-in only kicks off Azure Function work rather than doing the work itself, the call pattern still matters: a synchronous plug-in that calls an Azure Function's HTTP endpoint and waits for a response is still bound by the plug-in's own two-minute ceiling for that wait. If the downstream Function might take longer than a few seconds, the plug-in should hand off the request asynchronously — for example, by dropping a message on a queue and returning immediately — rather than blocking on an HTTP call to a Function that itself might run for minutes.