Four actors touch the request and the post names no record

Ryan Cunningham's September 3 post previewing PPCC 2026 walks one procurement request through Microsoft's process-first approach. An employee starts with a request in Copilot. An agent gathers the relevant supplier information and purchasing policies. A workflow routes the request and handles routine steps, and higher-risk exceptions go to the right person for review. Four actors take turns on one request, and the post never says where that request lives while they do.

We think that gap separates automation from traceability. Automation is the agent gathering and the workflow routing. Traceability is opening one request in December and seeing what came in, what the agent read, which branch the workflow took, who reviewed the exception, and what went out. That is what an internal auditor asks for, and no single log in the example can answer it alone.

Every actor keeps its own log, and none of the logs is the request

Each actor in the example already writes evidence. Copilot Studio keeps the agent's transcript. Power Automate keeps the run history. The approval action keeps who pressed the button and when. All of it is indexed by the thing that produced it, so you look it up by session, by flow run, or by inbox. The one key the requester holds, the request number on their sticky note, opens none of them.

A supplier phones in December to ask why an onboarding request from September was declined. The buyer has the request number. The platform team has a flow that reported success every day that month. The agent's transcript shows the policy text it summarised, and the policy has been revised twice since. Three people spend an afternoon lining up timestamps across three tools, and the agent has added a fourth.

A process record is a row that outlives every run

By a durable process record we mean one row in a Dataverse table that exists before the agent starts and is still there after the workflow finishes. It carries a business key the requester and the ERP both recognise, covered in our field guide to durable business keys. It carries a status the process owner can read without a developer, and who or what moved it there, with the agent named in the same actor column a person would occupy. And it carries a pointer to the evidence each actor used.

The evidence pointer is where the agent differs from the flow. A transcript records what the agent said about the supplier and the policy. A lookup on the request row to the supplier record and the policy version records what the agent read, which is what an auditor can check in March. Our sibling piece on the approval step in the same example argues that the reviewer needs to see what the agent gathered. The record is where that evidence has to sit for the reviewer to find it.

Grounding is the read direction, so ask about the write

The post lists a session titled Under the Hood: Dataverse, Copilot and Work IQ, on how Dataverse grounds agents in business data, meaning, and reusable business skills. Grounding is the read direction. The question we'd bring is the write. When the agent finishes gathering, does it update the request row itself, does it hand the result to a workflow that updates the row, or does nobody touch the row until the approval fires?

The answer changes the table design, so the Dataverse owner belongs in the room before the maker opens Copilot Studio. A row the agent writes needs an actor column that accepts an agent identity. It needs a status set that covers every state the agent can leave a request in, including gathered but not yet routed. And it needs auditing switched on for the columns the agent changes, because Dataverse audit history begins on the day auditing is enabled and not a day earlier. Decide all of that before the agent's first run rather than after the first dispute.

The governance session lists controls, and none of them is a trace

The Secure by Design session in the post covers permissions, data access, DLP policies, and enterprise AI guardrails, and the workshop adds governance, security, and application lifecycle management. Every one of those describes what the agent may do. None of them records what it did to a given request. That shows the first time someone needs to stop the process. We argued in why AI agents need a pause button that suspension should be an ordinary control. A pause only works when a record says which requests are mid-flight and what state each one is in. Without that row, pausing the agent means switching it off and hoping.

ALM cuts the same way. The columns the agent writes, the status choices, and the agent topic that decides what gets written all travel in the same solution, so a change to any of them should reach the same reviewer through the same pipeline. Our release checklist for shared solutions has the review conversation for that.

Trace one August request before you book the workshop

The conference runs October 27 to 29 at the MGM Grand, and the full-day workshop promises an end-to-end process with agents, Dataverse, human approvals, and ALM in one build. Before you book it, pick one process in your tenant that a flow or an agent already touches, take one request from August 2026, and trace it. What came in, what was read, which step ran, who signed, what went out. Count the tools you had to open.

If the whole trace sits in one Dataverse row with an audit history behind it, you are ready to let an agent take a bigger step. If it took three logs and a guess, the record is the first thing to build, and it belongs before the agent. Then take that request number to the Dataverse session and ask where the agent writes. Keep asking until the answer is a table and a column rather than a transcript.