Use Dataverse state tables for durable Copilot Studio processes
Diesen Beitrag auf Deutsch lesen
Persist long-running work in Dataverse, use guarded agent-flow transitions, and route uncertain cases to people instead of relying on chat memory.
TL;DR
Run long-lived Copilot Studio work from a Dataverse case table rather than a conversation. Use one guarded TransitionCase agent flow to validate state changes, write before side effects and confirm afterward. Store attempts, NextActionAt, confidence and an append-only audit trail; sweep due cases and send low-confidence work to NeedsHuman.
Original by Holger Imbery, on Holger Imbery - fieldnotes and insights. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Keep specialist agents narrow, put deterministic checks in agent flows, and persist confidence so uncertain extraction reaches human review.
- Admins/CoE: Make a single guarded flow the only writer of State, validate allowed transitions, and retain attempts, errors and audit entries for recovery.
- Leadership/Business: Define business states before building, then use the Dataverse table and Power BI to inspect queues, dwell times and recurring exceptions.
Frequently asked questions
Why should a Copilot Studio agent not hold the state of a long-running process?
The agent is treated as a stateless worker, and the process lives in a persistent Dataverse table.
What does the single-writer rule mean for the State column?
Only one component, a dedicated agent flow, may write the State column, and it validates transitions against an allowed list. Everything else reads the state and proposes transitions.
How can a process wait several days without keeping a Copilot Studio session open?
Scheduled sweeper flows check the NextActionAt timestamp and pick up cases that are due. An approval agent, for example, writes PendingApproval with a deadline for reminders and then stops, holding no session.