Graph to Functions Automation

Scenario Setup

An identity platform team wants to automate group-driven onboarding for a downstream SaaS app. Microsoft Graph is the authoritative source for group membership and application assignment changes, but the surrounding workflow still needs custom code to validate inputs, track progress, and export handoff artifacts for another system.

In this pattern, Graph starts the control-plane decision, Azure Functions runs the short-lived automation, Cosmos DB stores workflow state, and Azure Storage keeps exported files separate from the coordination data.

Why this pattern exists

This pattern exists because Graph tells you what changed, but it does not own the surrounding runtime workflow. Builders need a place to run code, persist checkpointed progress, and emit artifacts for systems that are outside Entra.

Azure Functions is the compute choice here because the work is event-driven and short-lived:

• poll Graph on a schedule or receive an operator-triggered request,
• validate and enrich the identity data,
• store workflow progress,
• export the downstream payload,
• finish quickly.

That shape matches Azure Functions for Identity Workloads better than a permanently running service.

Main Flow

sequenceDiagram
    autonumber
    participant Ops as Operator or Timer
    participant Func as Azure Functions
    participant Graph as Microsoft Graph
    participant Cosmos as Cosmos DB
    participant Blob as Azure Storage
    participant Downstream as Downstream System

    Ops->>Func: Start onboarding sync
    Func->>Graph: Read group and assignment state
    Graph-->>Func: Identity data
    Func->>Cosmos: Upsert workflow checkpoint
    Func->>Blob: Write export artifact
    Func->>Downstream: Submit artifact reference
    Func->>Cosmos: Mark step outcome
    Func-->>Ops: Status or telemetry

The architecture boundary is deliberate:

• Microsoft Graph Control Plane remains the source for users, groups, and application metadata.
• Azure Functions for Identity Workloads runs the glue logic.
• Cosmos DB for Identity State stores durable state such as checkpoints, retry counts, and downstream correlation IDs.
• Azure Storage Basics stores the exported CSV, JSON, or manifest artifact so large payloads do not pollute the state store.

Why Functions is the compute choice

Functions is the right fit here because the workflow is mostly coordination around Graph:

• each run is scoped to a bounded unit of work,
• the code mostly calls APIs and writes state,
• scaling pressure is intermittent rather than constant,
• the team wants managed triggers instead of operating a worker fleet.

If the workload later becomes continuously busy, needs special machine dependencies, or owns a larger service surface, the compute choice should be revisited.

Cosmos DB vs Azure Storage

Keep the storage boundary explicit:

• Use Cosmos DB for workflow state you query and update frequently, such as onboarding status, Graph checkpoints, retry metadata, and case ownership.
• Use Azure Storage for the exported artifact itself, such as a report, manifest, or raw payload handed to another system.

That split avoids turning Cosmos DB into a file store and avoids losing workflow structure inside opaque blobs.

Where Entra-specific behavior belongs

If the automation is reacting to provisioning status or hybrid sync outcomes, keep the product-specific mechanics in the existing Entra topics instead of reteaching them here:

• Entra Application Provisioning
• Entra Cloud Sync
• Entra Connect Sync

This quickstart is about the surrounding platform pattern, not the internals of those products.

When not to use it

Do not use this pattern when the main problem is a long-running coordinator, a continuously busy service, or a workload that depends on machine-level access.

It is also a poor fit when:

• the handoff is really a reliable workflow command that should move through Service Bus for Workflows,
• the data is a high-volume event stream that belongs in Event Hubs for Identity Events,
• the target system can only be reached from a private network segment or host-bound runtime.

In those cases, choose the messaging or hybrid pattern that matches the real boundary instead of stretching a simple Functions automation too far.