Business Process Automation Workflow

Define a bounded request

Use an illustrative office-equipment request for a replacement monitor. The request contains a case ID, requester, department, requested item and business reason. The workflow checks required fields and prepares the request for an authorised reviewer. It does not place an order merely because the form was submitted.

Write the finished outcome: the approved item has been arranged and the requester has a recorded handover, or the request has been declined or cancelled with a reason. That definition separates a completed process from a successfully sent notification.

Describe states and permitted moves

Start with a small set of states: received, needs information, awaiting review, approved, being arranged, completed, declined and cancelled. For each move, state who or what may cause it and what evidence is required. Completion might require an item reference and a handover date.

A request needing information returns to review only when the missing fields are supplied. An approval belongs to the submitted item and version. If the requested item changes, define whether renewed approval is required. Do not allow an old approval to authorise a different purchase by accident.

Specify actions and failure handling

List each action with its input and expected saved result. Creating an arrangement task should save the resulting task ID against the case. If the next notification fails, the workflow can retry the notification without creating another task.

Use a stable event or case reference to recognise repeated submissions. A retry after a timeout needs a check for an action that may already have succeeded. “Try again” is not a complete recovery rule when the action can create a purchase, booking or customer message.

Keep failures in a visible queue with a named owner. Record enough information to diagnose the failed step without copying unnecessary personal data into logs. The owner should know whether to retry, correct an input or complete a manual handoff.

Write acceptance checks before building

Use test cases with expected outcomes. A complete request should reach review once. A missing department should wait for information. A declined request should create no arrangement task. A repeated approval event should not create a second task. A changed item should follow the renewed-review rule.

Also test cancellation after arrangement starts. The workflow may need to ask a person to stop or return an item; it cannot assume an external commitment has been reversed. Check the resulting records and notifications, not only whether the run finished without an error.

Use the specification to agree the work

Automations For Business can turn a defined specification into a custom workflow with your existing tools and human approval steps. Share a redacted request, the permitted decisions and the acceptance checks. Agree who will maintain the rules after handover and how the process can be paused safely.

The worksheet below can serve as a build brief. Complete one ordinary path and the most important exceptions first. A small, testable workflow is easier to review than a diagram containing every possible future feature.

Your ready-to-use checklist

Make the next step clear.

Sources and notes

Sources checked on October 22, 2026.

• Microsoft: approval flows

  Official documentation for combining an automated flow with a person’s approval.

• Microsoft: test cloud flows

  Official guidance for testing automation before relying on its output.

• Microsoft: troubleshoot a cloud flow

  Reference for investigating failed runs and connections.