Serverless compute with Azure Functions

There’s a point in many Power Platform projects where the work no longer belongs inside the platform: a heavy calculation, a third-party integration, a large file to process, or a custom API that other systems will call. Azure Functions are the natural home for that work. They’re serverless — you write the logic, and Azure runs and scales it on demand without you managing servers — which makes them a cost-effective, elastic complement to Dataverse and Power Automate.

You pay for what you use, they scale automatically under load, and they give you the full power of a real programming environment when the platform’s declarative tools aren’t the right fit.

Triggers and bindings

A Function is defined by its trigger — what causes it to run:

• An HTTP trigger exposes a custom API that anything can call.
• A Service Bus trigger processes messages from a queue or topic.
• A Blob trigger reacts to a file arriving in storage.
• A Timer trigger runs on a schedule.

Bindings then make it easy to read inputs and write outputs — to storage, queues, or other services — with minimal plumbing, so the Function code stays focused on the logic rather than boilerplate. This trigger-and-binding model is what makes Functions so quick to build: you declare how the Function connects to the world, and Azure wires it up.

Common patterns with the Power Platform

A few patterns come up again and again:

• The platform calls out. A plugin or a flow invokes an HTTP-triggered Function to perform work the platform shouldn’t do itself — a complex calculation, a call to a specialised API, document generation.
• The Function receives events. A Function catches a webhook from an external system and updates Dataverse, bringing outside events into the platform reliably.
• The Function is the engine. At the end of a messaging pipeline, a Service Bus-triggered Function does the real processing after the broker has safely decoupled it from whatever raised the event.

In each case the Function provides scale and reach that the platform alone doesn’t have.

Build for scale and failure

Serverless scales automatically, which is powerful but demands discipline. Because many instances of your Function may run at once, and because a message can sometimes be delivered more than once, Functions should be:

• Stateless. Keep no state in memory between invocations; treat each run as independent.
• Idempotent. Running the same work twice should not corrupt data. Use a stable key to detect and skip duplicate processing.
• Respectful of limits. When talking to Dataverse or other APIs, honour rate limits and batch sensibly rather than hammering them from hundreds of parallel instances.

Failure is inevitable at scale, so pair Functions with retries and, where a message broker is involved, dead-lettering — so a message that can’t be processed is set aside for investigation rather than silently lost.

Choosing a hosting plan

Functions run on different plans, and the choice affects cost and behaviour. The Consumption plan scales to zero and bills per execution — ideal for spiky or occasional workloads. Premium and dedicated plans avoid cold starts and give you more predictable performance and networking options, which matters when a Function must respond quickly or reach into a private network. Matching the plan to the workload keeps you from either overpaying or being caught out by latency.

Observability

A Function you can’t see into is a liability. Wiring in Application Insights gives you end-to-end tracing, metrics and alerting, so you know how a Function is performing and can diagnose problems quickly when something goes wrong. Correlating a Function’s logs with the flow or plugin that invoked it turns “something failed somewhere” into a precise, answerable question.

Security

Functions often sit on the boundary between your platform and the outside world, so secure them deliberately. Protect HTTP endpoints with keys or, better, identity-based auth; store secrets in Key Vault rather than in configuration; and give the Function a managed identity so it can reach Dataverse and other Azure resources without credentials in code.

Wrapping up

With observability and sensible design in place, Azure Functions become a dependable, scalable engine sitting quietly behind your Power Platform solutions — doing exactly the work the platform is not the right place for. They’re the piece that lets a low-code solution reach as far as it needs to, without compromising on scale, integration or control.