Original Business Dynamics diagram: revalidate the approved proposal before execution. View the full-size workflow.
A transportation planner approves a carrier assignment at 9:10. The agent resumes at 9:25. During the wait, someone has changed the pickup window and another operator has placed the load on hold. The approval is genuine. The proposed action is now wrong.
This is an illustrative engineering example, not a report of a customer incident. It exposes a problem that a simple Approve button cannot resolve: a person reviews one version of a business operation, while the software may later execute another. In enterprise workflows, the interval between review and execution deserves as much attention as the review screen.
Approvals now appear directly in agent development tools. Microsoft's current documentation describes multistage reviews in Copilot Studio agent flows, including human stages, AI stages and conditional routing. That particular capability is documented as preview, with production-use restrictions. Its availability should not be confused with a complete authorization design. The application still needs rules governing what a decision permits and when that permission ends. Microsoft documentation
Consider a shipment reassignment workflow. The agent may collect delivery constraints, compare available options and prepare a recommendation. Before requesting approval, the application should save the precise proposal: shipment ID, current assignment, proposed carrier, pickup window, quoted amount and currency, and any conditions the reviewer needs to understand.
Give that proposal its own identifier and revision. Record which source records informed it. A reviewer should be able to see the existing value beside the proposed value, the reason for the change, and links to the underlying order or quote. A conversational summary can explain the recommendation, but the system needs structured fields to enforce it.
For example, an approval record could authorize proposal P-184 revision 3, assigning shipment S-204 to carrier C-17 for a specified pickup window and quoted amount. It could record a named reviewer and an expiration time chosen by the business. Those identifiers and values are illustrative. They show the shape of the contract between the reviewer and the execution service.
The model should not regenerate the approved fields after the decision arrives. If it finds a better alternative, that becomes another proposal. Silently swapping in a new carrier would change what the person authorized, even if the model considers the difference beneficial.
OWASP's transaction authorization guidance provides useful foundations: present significant transaction data clearly, enforce authorization on the server, protect transaction details from modification, and check authorization at execution. Applying those principles to an agent means binding the decision to the saved proposal rather than treating an approval message as general permission to continue. OWASP guidance
After approval, the execution service should retrieve the current shipment and the relevant constraints. It should confirm that the proposal remains active, the decision has not expired or been revoked, and the reviewer has the required authority under the organization's policy. It should also confirm that the service itself is allowed to perform the write. Human approval does not supply missing system permissions.
The important comparison is between the assumptions supporting the proposal and current business state. A changed customer delivery address, a load hold, an expired quote or a different carrier assignment may invalidate the decision. A corrected internal note may have no bearing on it. Define that distinction deliberately; otherwise every harmless edit can restart the approval process.
For a record stored in Dataverse, an ETag can support optimistic concurrency. Microsoft documents using a retrieved ETag in an If-Match request so an update succeeds only when the record version still matches; a mismatch produces a 412 Precondition Failed response. The table must support optimistic concurrency. Use the actual version value, not a wildcard, when the goal is to detect an intervening change. Dataverse conditional operations
That protection covers the record being updated. It does not prove that a related quote remains valid or that a dock appointment is still available. A separate read followed by a write also leaves a race between the two. Where several records define a valid decision, put validation and mutation inside the destination's transaction boundary when supported. Otherwise, use reservations or short-lived holds and define how to recover if a dependent operation fails.
When the checks fail, the agent should explain the specific difference and prepare a fresh proposal if appropriate. The reviewer can then decide against the new facts. Reusing the old approval after rewriting its assumptions would defeat the control.
Workflow persistence solves another part of this problem. LangGraph's interrupt mechanism saves execution state and lets a workflow wait for external input. Its documentation also explains that resuming restarts the interrupted node from its beginning. Code before the interrupt can therefore run again. Durable checkpoints are useful, but a resumed workflow still needs application-level authorization checks. LangGraph interrupts
Keep irreversible actions outside the proposal-building and review steps. Store the decision durably, validate it when execution starts, and record the destination's result. A rejection, cancellation, expiration and successful execution should be distinct states. An approval that has already been consumed should not remain an open instruction.
This complements the duplicate-protection approach covered in When an AI Agent Retries. An operation ID can prevent the same write from happening twice. It cannot make an outdated decision appropriate. Both controls belong in the execution path.
There is a cost to strict validation. Broad record-version checks are straightforward but can trigger unnecessary reviews. Comparing only selected business fields reduces those interruptions, while requiring careful maintenance as policies change. Short expiration periods reduce exposure to stale information but can burden busy reviewers. Choose those rules per action: reallocating a trailer and committing a freight charge need different treatment.
A useful pilot should test an approval that arrives after a load hold, a quote that expires during review, a changed pickup window, a revoked decision and a worker that resumes twice. These cases reveal whether the software enforces the decision the reviewer actually made. Count stale proposals blocked and repeat reviews caused by irrelevant edits, alongside completion time.
The transportation and yard workflows shown in our featured applications illustrate the kind of connected operation where these boundaries matter. The pattern described here is an implementation recommendation, not a claim that those applications already implement every control. If you are planning an agent that changes operational records, Business Dynamics can help define the approval and execution boundary before that workflow reaches production.
