Durable Functions

Pick a backend

Task hubs hold an app's orchestration state. Names are alphanumeric, 3–45 characters. Each app, and each staging slot, needs its own task hub: apps sharing one compete for messages and orchestrations get stuck. The default (the app name) avoids this; if you set hubName in host.json, make it an app setting (%TASKHUB_NAME%) and slot-sticky.

Durable Task Scheduler with a managed identity

// Durable Task Scheduler + task hub, with a user-assigned identity granted access to the hub
param location string = resourceGroup().location
param schedulerName string
param taskHubName string = 'orders'
param identityPrincipalId string

param ipAllowlist array // ranges allowed to reach the endpoint

resource scheduler 'Microsoft.DurableTask/schedulers@2026-02-01' = {
  name: schedulerName
  location: location
  properties: {
    ipAllowlist: ipAllowlist
    sku: {
      name: 'Consumption'
    }
  }
}

resource hub 'Microsoft.DurableTask/schedulers/taskHubs@2026-02-01' = {
  parent: scheduler
  name: taskHubName
}

// Durable Task Data Contributor
var durableTaskDataContributor = subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '0ad04412-c4d5-4796-b79c-f76d14c8d402')

resource hubAccess 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  scope: hub
  name: guid(hub.id, identityPrincipalId, durableTaskDataContributor)
  properties: {
    roleDefinitionId: durableTaskDataContributor
    principalId: identityPrincipalId
    principalType: 'ServicePrincipal'
  }
}

output endpoint string = scheduler.properties.endpoint

• Roles: Durable Task Data Contributor (everything; most apps), Durable Task Worker (processing only), Durable Task Data Reader. Scope to the task hub; the scheduler scope covers all hubs. Without a role for yourself the dashboard shows Unknown error retrieving details of this task hub.
• App settings: DURABLE_TASK_SCHEDULER_CONNECTION_STRING = Endpoint=<endpoint>;Authentication=ManagedIdentity;ClientID=<identity client ID> (omit ClientID for a system-assigned identity) and TASKHUB_NAME.
• host.json: extensions.durableTask.storageProvider = { "type": "azureManaged", "connectionStringName": "DURABLE_TASK_SCHEDULER_CONNECTION_STRING" }, hubName = %TASKHUB_NAME%. Non-.NET apps need extension bundle [4.32.0, 5.0.0) or later. (Microsoft's provider comparison table still says bundle support is "coming soon"; the quickstart is newer.)
• Limits: schedulers and task hubs per region and subscription depend on the SKU; a Consumption scheduler holds at most five task hubs, and task hub quotas can't be raised. Each work-item completion is at most 3.9 MB; larger payloads need the large-payload feature.
• Deleting a scheduler with task hubs in it fails with CannotDeleteResource Cannot delete resource while nested resources exist…: delete the task hubs first.

Azure Storage backend with identity: identity-based AzureWebJobsStorage (reference/functions/hosting-and-host-storage.md) plus Storage Queue, Blob and Table Data Contributor. On Flex Consumption, Microsoft advises one always-ready instance for the durable group and a queue polling interval of 10 seconds or less.

TypeScript (Node.js v4 model, durable-functions 3.x)

import { type HttpRequest, type HttpResponse, type InvocationContext } from "@azure/functions";
import * as df from "durable-functions";
import { type OrchestrationContext, type OrchestrationHandler, type ActivityHandler } from "durable-functions";

// Orchestrator: deterministic; yield tasks, never await.
const fanOut: OrchestrationHandler = function* (context: OrchestrationContext) {
  const items = context.df.getInput<string[]>() ?? [];
  const retry = new df.RetryOptions(5000, 3);
  const tasks = items.map((id) => context.df.callActivityWithRetry("processItem", retry, id));
  const results: number[] = yield context.df.Task.all(tasks);
  return results.reduce((a, b) => a + b, 0);
};
df.app.orchestration("fanOut", fanOut);

const processItem: ActivityHandler = async (id: unknown, ctx: InvocationContext): Promise<number> => {
  ctx.log(`processing ${String(id)}`);
  return 1; // activities do the I/O
};
df.app.activity("processItem", { handler: processItem });

df.app.client.http("startFanOut", {
  route: "orchestrators/fanOut",
  methods: ["POST"],
  extraInputs: [df.input.durableClient()],
  handler: async (req: HttpRequest, client: df.DurableClient, _ctx: InvocationContext): Promise<HttpResponse> => {
    const instanceId = await client.startNew("fanOut", { input: await req.json() });
    return client.createCheckStatusResponse(req, instanceId);
  },
});

Orchestrators replay from history, so they must be deterministic: use context.df.currentUtcDateTime, durable timers and activities instead of clocks, random values, network calls or await. Breaking changes to in-flight orchestrations leave them stuck: version them.

When orchestrations don't progress