Graph $batch Dependent Requests and Ordering Prompt
Design a Microsoft Graph $batch payload that chains dependent requests (create team, then add members, then post welcome) using the dependsOn ordering, with per-request error handling and a 20-request chunking strategy.
- Target user
- Engineers automating multi-step Teams provisioning via Graph
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior platform engineer who has used Graph $batch with dependsOn to run multi-step Teams provisioning in a single round trip and handled the partial-failure cases. I will provide: - The ordered steps you want to batch (e.g. create team -> add channels -> add members -> post card): [STEPS] - The total count of sub-operations (members, channels) per provisioning run: [COUNTS] - Your auth model (app-only vs delegated): [AUTH] - How you want to handle a mid-batch failure: [FAILURE POLICY] Your job: 1. **Build the batch** — construct the JSON batch request with each step as a request object (id, method, url, body, headers); show a real example for the [STEPS] above. 2. **Order with dependsOn** — use dependsOn so step 2 only runs if step 1 succeeded; explain that Graph evaluates dependencies and that a failed dependency yields a 424 Failed Dependency for downstream requests. 3. **Respect the 20-request limit** — a single $batch holds at most 20 requests; show how to chunk [COUNTS] sub-operations across multiple batches and how to thread state (the new team id) from batch 1 into batch 2. 4. **Per-request status** — parse the responses array, mapping each id back to its step, and surface which sub-operations succeeded vs 424'd vs 429'd. 5. **Throttling inside batch** — individual sub-requests can return 429 with their own Retry-After; show selective retry of only the throttled sub-requests rather than replaying the whole batch. 6. **Idempotency** — make re-running a partially-failed provisioning safe (skip already-created resources) so a retry doesn't duplicate channels or members. Output as: (a) the full $batch JSON with dependsOn, (b) the chunking plan across the 20-request limit, (c) the response-parsing and per-request status map, (d) the selective-retry logic for 429s, (e) the idempotent re-run strategy. Bias toward: dependsOn for ordering, selective retry over full replay, and idempotent re-runs.
Why this prompt works
The Graph $batch endpoint is the right tool for multi-step Teams provisioning, but most examples show three independent requests bundled for a single round trip and stop there. Real provisioning is dependent: you can’t add members to a team that doesn’t exist yet. This prompt centers the dependsOn ordering primitive, forcing the design to express “step 2 only runs if step 1 succeeded” and to handle the 424 Failed Dependency that Graph returns downstream when an early step fails. That single detail separates a batch that provisions cleanly from one that fires member-adds at a team id that was never created.
The prompt also refuses to ignore the platform’s two unforgiving constraints: the 20-request-per-batch ceiling and per-sub-request throttling. By requiring an explicit chunking plan and the threading of state (the new team id) from one batch into the next, the output handles the common case of provisioning more than twenty members or channels. By requiring selective retry of only the sub-requests that returned 429 — each with its own Retry-After — it avoids the classic mistake of replaying an entire batch and duplicating everything that already succeeded.
Finally, the idempotency requirement makes partial failure survivable. Provisioning runs will fail halfway, and the difference between a calm retry and a duplicated mess is whether the re-run skips already-created resources. Asking for that explicitly produces a provisioning flow you can safely run twice, which in practice is the only kind worth shipping.