Test the handover your team will depend on.

Name the input, permitted output and person responsible for using it. Preparing a draft from an approved call recording is a different permission from sending a follow-up to the customer. A correct summary does not prove that the workflow is allowed to send it. Use Choosing an AI workflow if the task itself still needs a clearer boundary.

Separate fields copied from a source, values produced by a fixed rule and interpretations requiring judgement. A quantity quoted in an RFQ should remain traceable to its source. A proposed next step from a sales call should be marked as a proposal until the responsible person approves it.

State what the workflow must refuse, including unsupported material, missing access and actions outside scope. OWASP’s excessive-agency guidance calls for permissions and authorisation beyond model instructions. In the test, an unapproved operation should remain unavailable even if source text asks for it.

Choose authorised, representative inputs and remove information unnecessary for testing. Include routine work, known exceptions and awkward combinations. Agree the expected result before running a case, then keep some cases aside while the workflow is adjusted so the final check includes unfamiliar material.

For RFQ preparation, include a complete request, a line without a unit, conflicting dates, a later revision and an unsupported attachment. For sales-call intelligence, include a correction later in the conversation and a suggested next step that nobody accepted.

Test text that looks like an instruction but belongs only to the source. A customer document asking the system to ignore its rules or copy information elsewhere must not expand the workflow’s authority. Keep the test record free of real credentials and use authorised test destinations.

Before execution, give every case a short ID, input reference, expected output, forbidden action and reviewer. Keep evidence against that ID. This makes a disagreement about a result specific enough to resolve.

Incomplete input: check that the result names a missing value or conflict without inventing an answer. Include uncertain people, dates, quantities and account matches. A source-linked held case can satisfy the contract when the input is insufficient.

Unavailable connection: interrupt a required lookup or save. The operator should see what is unavailable, what has been retained and whether the work is queued, failed or still uncertain. “Saved” should mean the destination accepted the record, not that a request was merely attempted.

Repeated input: replay an event, click twice and retry after a lost response. Stripe documents that webhook events can be delivered more than once. Check each connection’s actual behaviour and ensure a retry cannot silently create another note, job or message for the same intended action.

Wrong access: attempt to open a result as an unauthorised user or another account. Check enforcement at the server and destination, including revoked or expired access, rather than relying on links being hidden in the interface.

Partial completion: let one step succeed and the next fail. If the person record exists but the enquiry note does not, the recovery screen must show that distinction. The operator needs a way to reconcile what happened before repeating an action whose result is unknown.

Ask the future user to find a source, identify an unresolved field, correct an input and choose the next action. Let them work without explaining the intended behaviour. Note any missing context that belongs in the output or operating instructions.

Use their working conditions: a phone where briefs are read on phones, keyboard navigation, a slow connection and a failed upload. Check that feedback is immediate, errors explain a useful next action and entered material is preserved where it can safely be retained.

Where the workflow assigns work, include a missing owner and an unavailable recipient. The lead-routing rules guide helps define the fallback before the test. A technically correct brief is an incomplete handover if nobody responsible can find it.

Record pass, fail or open against each expected result. Retest a repaired failure and the neighbouring behaviour it could affect. Keep unresolved conditions explicit; a successful screenshot should not stand in for checks that have not run.

Keep scope, access, configuration location, test cases, known limits and recovery instructions together. Name the operator, the person authorised to approve changes and the person who can pause the workflow or revoke a connection. CRM data quality needs to be settled where acceptance depends on record identity or source priority.

For each case, retain the input reference, expected and observed result, status, evidence location and reviewer. Repeat representative cases when a prompt, rule, model, connection or permission changes. One successful model response is insufficient evidence of consistent performance across the agreed task.

An agent operating contract adds explicit tool authority, resource limits and stopping conditions. The implementation plan places these checks before handover. Retain the cases, observed results and open limits so the operator knows what was checked and when to seek review.

In a ClarityRev AI workflow, we document 20 real routine and exception cases from your history, agree the expected result, run all 20 and deliver them with the workflow. The cases are not a guarantee against every future error.