What to test before a workflow goes live

Define what finished means

A workflow demonstration does not establish that staff can hand work over to it. Acceptance should answer how inputs arrive, who confirms outputs, who handles failures and where the team sees everyday records.

Write a short acceptance scope. “Prepare a reviewable record from one purchase-document type and write it to the business system after staff confirmation” is easier to test than “automate document processing”. Name the document types, systems, user group and manual actions retained in the first release.

Use work the team will actually encounter

Frontline staff and the business owner should prepare samples covering normal tasks, less common situations and the exceptions that currently take the most time. More samples are not automatically better, but every sample should not come from the same ideal format.

For each, record the input, expected result and reviewer. Agree the purpose and access arrangements for personal information. Where fictional or de-identified records cover the test adequately, use them first.

Include relevant differences in language, document quality, accessibility and user groups. Look for cases where the same error repeatedly disadvantages a particular group. Reviewers need enough subject knowledge, time and authority to challenge a result and stop the next action; an approval button alone does not establish meaningful review.

Keep a separate set of samples that is not used for repeated adjustments, and test it near acceptance. This helps reveal whether the workflow handles new examples within scope, rather than only the documents used while configuring it.

Test more than a successful run

Cover the following situations and specify how staff will know they need to act:

Situation	Behaviour to check
Complete information	Correct output reaches the next step
Missing required field	Gap remains visible; record is not submitted as complete
Duplicate request	Duplicate is identified or flagged before repeated action
Failed connection	Visible status and no duplicate write on recovery
Required approval	The action waits for the agreed approval
Update or cancellation	Superseded status stops triggering later actions

For generated text, also test missing answers, conflicting information and questions beyond the approved scope. Business reviewers check facts and applicability. Technical reviewers check records, permissions and connection outcomes. Both are needed.

Try a request for another person’s information, an instruction hidden in an incoming document and an output sent to the wrong audience. Check that access boundaries still apply, unexpected instructions do not override the agreed task, and staff can identify and contain a failure.

Agree checkable acceptance criteria

Tie criteria to fields, actions and business records: required information is present, associations are correct, a specified review happens before sending, and the resulting system record can be found.

If using accuracy or completion rates, define the denominator and passing conditions first. Field-level results differ from whole-transaction results. State how items referred to staff are counted. Time-saving measurements should include input preparation, review, corrections and exception handling.

Wrong recipients, repeated charges or overwritten records should not be hidden by a good average across ordinary tasks. Confirm how those actions are held or prevented before setting an overall pass threshold. The business owner and delivery team should agree the criteria before seeing the final results.

Gather evidence from limited live use

Begin by preparing outputs for staff to compare with the current process. A defined user group can then handle a limited category of live work. Record volume, staff time, issues and corrections during that period. A pilot does not need to move the whole business at once.

Before launch, name an everyday workflow owner, someone able to pause and restore it, and a technical support contact. When paused, unfinished work should enter a visible queue with a known manual route. For messages or system updates, establish which actions already happened and which remain pending.

Explain relevant automated uses to the people affected and give them a practical route to ask for human review or correct information. Record how reported problems reach the owner, what is paused while they are investigated and how affected records are corrected.

Make the handover usable by another colleague

Organise the handover around practical materials:

• The current workflow, included scope and manual exceptions.
• Account ownership, access responsibilities and subscription costs.
• How to view status, correct records and handle common failures.
• Accepted samples, open issues and agreed follow-up work.
• How to update reference information or rules and obtain support.

Ask the receiving staff member to complete an ordinary task and an exception. That tests the handover more directly than recording that training took place. Agree a review point and use operating records to decide whether the workflow is ready to expand.

Keep the accepted workflow version and test findings together. Changes to the model, supplier, reference information or workflow may require another test of the affected parts. Errors and complaints should also trigger a review of whether the original checks still work. See J2K’s delivery methods for the records used at each stage.

If the first scope is still unclear, start with the first-project guide. When comparing delivery proposals, use the implementation-partner guide to confirm responsibilities.

Reference: Responsible AI Guidance for Businesses · MBIE.