Guide · AI employees
Where to Put Approval Steps in an AI Workflow
Choose review points that catch consequential mistakes without making someone approve every small step.
An approval button is useful only when the person clicking it can tell what will happen next. A preview that says "Ready to publish" isn't enough if nobody can see the destination, audience, or final content. Place reviews around decisions with consequences, then give the reviewer the information needed to make them.
Separate preparation from action
Researching a topic, organizing notes, and drafting copy usually produce work that can be inspected before anyone outside the team sees it. Sending the email or publishing the page changes that situation. Those steps deserve a clear boundary.
Consider a hypothetical campaign workflow. The researcher gathers sources. The writer prepares a draft. A reviewer checks the offer and wording. The system then prepares the final message for a specific audience. Approval of the draft shouldn't silently become permission to send it to any list the system can find.
Review the thing that will actually happen
A useful approval screen shows the final artifact and the exact scope of the action. For an email, that includes the message, subject, sender, recipients, and intended time. For a CRM update, show the proposed field changes and which records they affect.
If you approve one version and the workflow edits it afterward, that approval is stale. The implementation should either require another review or make a narrow, previously agreed class of changes. Decide that behavior while designing the workflow, not after a reviewer discovers the live result differs from the preview.
Put a person where judgment is needed
A factual product claim, an unusual customer request, or an ambiguous record match may need someone who understands the business. Assign that responsibility to a role with the relevant context. Sending every question to the busiest person in the company creates a queue nobody enjoys.
Tell the reviewer what is uncertain. "This contact has two possible matches; compare the phone and company fields" is useful. "Please review" makes them reconstruct the entire task. A short explanation of the decision often matters more than another dashboard.
Decide what happens while you wait
A pending review needs an owner, a visible status, and a way to expire. Otherwise a draft can sit for weeks and then resume with old information when someone finally clicks approve. Some tasks should be canceled after a deadline; others should return to preparation for a fresh check.
Also make rejection useful. Let the reviewer explain whether the task needs a correction, more evidence, or a different approach. The workflow should preserve that explanation with the next attempt so the same issue doesn't keep coming back.
Try the unpleasant cases before launch
Walk through the review step using deliberately awkward examples. Change the audience after approval. Remove the reviewer from the team. Let the offer expire while the task waits. Try to approve an older version after a newer draft exists.
The aim is a review process people can trust enough to use. A clear boundary at the consequential step is usually easier to maintain than a string of vague approvals throughout the entire workflow.
- Can the reviewer identify the exact version and destination?
- Does a changed action require the right approval again?
- Can a teammate see who is holding the decision?
- Can the task be canceled without leaving a half-finished action behind?