SYNTHETIC EXAMPLE • WEB-030 • 1 OCTOBER 2026
Workflow automation planning worksheet
Static worksheet: copy the tables into your working document or print this page. No data is submitted, saved or connected to a system. All sample records, amounts and rules are invented. This is not a client case, purchasing policy or executable workflow.
Return to the guide · Open the synthetic flow diagram
On small screens, scroll the table horizontally to see all columns.
Automation opportunity matrix
| Candidate | Trigger and inputs | Rule and action | Owner and completion evidence | Exception / first-pilot consideration |
|---|---|---|---|---|
| Purchase approval | Submitted request: ID, revision, requester, purpose, amount, currency, cost centre | Route to authorized approvers; create an internal task after required approvals | Operations lead; decision record and purchasing task ID | Missing input → requester; rejection → close; overdue → authorized deputy. Good candidate when authority rules are agreed. |
| Employee onboarding | HR-confirmed record: employee ID, start date, manager, location, approved access profile | Create the appropriate HR, equipment and access-review tasks | HR coordinator; confirmed completion of assigned tasks. IT owns access | Missing manager → HR; repeated event → no duplicate account; failed account task stays open. More dependencies across systems. |
| Invoice review | Invoice intake: supplier ID, invoice number, currency, amount, order or receipt reference | Check duplicate and matching rules; route for review; payment is separate | Accounts payable; review status and accounting reference | Mismatch → held review; unavailable accounting system → recovery. Needs dependable supplier IDs and match rules. |
| Service routing | Submitted request: ID, category, location, contact, priority evidence | Map category/location to queue; assign ticket and acknowledge | Service coordinator; ticket ID and team acceptance | Unknown category → triage; duplicate → reuse ticket; failed destination → visibly unassigned. Can start inside one platform. |
Worked approval rule card
- Required inputs: request ID, revision, event ID, requester, purpose, amount, currency and cost centre. Positive amount in SAR only. Missing or invalid input returns for correction before approval.
- Up to and including SAR 5,000: department manager. Above SAR 5,000: manager then finance. The requester must not approve their own request; missing or conflicting approvers go to operations for authorized reassignment.
- Record approver, decision, reason, timestamp and revision. Rejection closes that revision without a task. After two business days without a decision at either approval stage, route to an authorized deputy and keep pending. Specify the working calendar and timezone before implementation.
- Approval creates one internal purchasing task, not an order or payment. Store its destination ID. A completed technical run alone does not prove the task exists.
- Event key = request ID + revision + event ID. Ignore identical repeats; quarantine conflicting content. Unique action key = request ID + revision + create-task. The destination must enforce uniqueness, or the integration must reserve this key atomically before task creation. Logging a key alone is insufficient. Test concurrent duplicate events.
- Before task creation, changing amount, purpose or cost centre creates a new revision, cancels pending old approvals and requires fresh approval. Ignore late decisions for old revisions. After task creation, use an owned amendment/cancellation procedure.
- A task-creation timeout may hide success. Assign a recovery owner and reconcile the destination using the action key before retrying. Keep the last confirmed state, error, next action and due time. Limit retries for known temporary failures.
On small screens, scroll the table horizontally to see all columns.
Synthetic acceptance cases
These expected results were checked with a local decision model. They do not test any real platform, connector, permissions or concurrent execution. Test those in your implementation environment before release.
| Case | Starting input / event | Expected output |
|---|---|---|
| T01 | 4,800 SAR; valid inputs; manager approves | One task |
| T02 | 5,000 SAR; manager approves | One task; inclusive boundary |
| T03 | 5,000.01 SAR; manager approves; finance pending | Wait for finance; zero tasks |
| T04 | 5,000.01 SAR; manager then finance approve | One task |
| T05 | 5,000.01 SAR; finance rejects after manager approval | Rejected; zero tasks |
| T06 | 4,800 SAR; cost centre absent | Return for correction; zero approvals or tasks |
| T07 | 0 SAR, negative amount, or currency other than SAR | Return for correction; zero tasks |
| T08 | Requester is the assigned approver, or approver missing | Operations assigns an authorized different approver; zero tasks |
| T09 | Same event key and same content delivered twice | Ignore repeat; no extra approval or task |
| T10 | Same event key arrives with changed content | Conflict for review; no new action |
| T11 | Two business days without a decision | Pending; route to authorized deputy, never auto-approve |
| T12 | Task creation times out; outcome unknown | Recovery owner checks destination before retry; do not mark complete |
| T13 | Amount changes before task creation; old approval arrives later | New revision requires fresh approvals; ignore old decision |
| T14 | Different event attempts task creation for a completed revision | Reuse saved task ID; no second task |
| T15 | Manager rejects a 4,800 SAR request | Rejected; zero tasks |
Your first workflow: complete before a pilot
| Planning question | Your answer / owner / evidence |
|---|---|
| Process name and business outcome | ________________________________ |
| Process owner / deputy / recovery owner | ________________________________ |
| Trigger, source system and destination | ________________________________ |
| Inputs, definitions and source of truth | ________________________________ |
| Authority rules and who approves them | ________________________________ |
| Allowed states and completion evidence | ________________________________ |
| Duplicate / conflicting event handling | ________________________________ |
| Missing input / rejection / late response path | ________________________________ |
| Timeout reconciliation and retry limit | ________________________________ |
| Who can read, edit, approve and recover | ________________________________ |
| Stop switch and manual fallback | ________________________________ |
| Baseline: observed volume, waiting time and exceptions | ________________________________ |
| Acceptance cases, actual results and reviewer | ________________________________ |
| Handover: connections, rule version, field map, change procedure | ________________________________ |
| Monitoring: oldest pending item, unowned exceptions, failed actions, mismatched destination records | ________________________________ |
| Review cadence, escalation owner and go/no-go decision | ________________________________ |