All guides

Supervised automation

Where human approvals belong in automated workflows

An approval should tell a person exactly what will change, why it is proposed, and what evidence supports it. A button labeled approve is not enough on its own.

Define actions and authority separately

A workflow can prepare a proposed CRM update without being allowed to commit it. It can draft an email without sending it. During discovery, list each action and identify who can authorize it in the approved environment.

Use the company's actual access policy. Reading a record, creating a draft, changing a live record, and communicating outside the company may require different permissions. Avoid giving a pilot wider access simply to reduce setup effort.

Put the decision before the consequence

Make the review useful

Present the source facts, proposed action, affected system, and any uncertainty together. The reviewer should be able to reject or correct the proposal without reconstructing the entire workflow. Define who takes over when the normal reviewer is unavailable.

Treat changed data as a new decision

Approval should refer to a specific proposal. If the record, recipient, amount, attachment, or other consequential input changes, recheck the proposal before execution. Do not reuse an earlier approval for a materially different action.

Verify the result after action

Record what was approved and compare the finished state with the intended result. An attempted click or a submitted request is not proof that the business system accepted the change. Define what happens after a timeout or partial failure before the pilot starts.

Measure review effort

Approval time belongs in the pilot's hands-on measurement. If reviewers spend longer checking proposals than performing the original task, improve the proposal and its evidence or reconsider the workflow scope.

Read about MARPBOUND security boundaries and measuring the full supervised workflow. Specific controls and integrations must be assessed for each deployment.