Follow one daily operations workflow for a fictional Auckland wholesaler. See what the digital employee reads, which rules it applies, where it stops for a person, and what it writes back after approval.
This fictional business, its records, people, amounts and run results are illustrative. It is not a customer story or a completed client result. It shows one possible recovery path, not a promise that every system or failure can recover in the same way.
The example run reads only the records needed for this workflow. Each record below is synthetic.
This fictional business, its records, people, amounts and run results are illustrative. It is not a customer story or a completed client result. It shows one possible recovery path, not a promise that every system or failure can recover in the same way.
Promised dispatch was yesterday. No courier scan is recorded.
The unit number required by the delivery rule is blank.
8 units on hand, reorder point 12, and no open purchase request.
Accounting shows paid. The order record still shows payment pending.
The agreed follow-up window has passed with no reply recorded.
Before a live connection is enabled, the workflow gets a system-by-system contract. This synthetic example shows what each connector may read, prepare, write after approval, and how it fails closed.
The digital employee does not invent a response when the data is incomplete or conflicting. It prepares what the rule allows and sends the rest to a person.
Stock is at or below its reorder point and no request is open
A purchase request using the agreed reorder quantity
A nominated person must approve any spend
A paid order is past dispatch time with no courier scan
An internal dispatch task and a customer update draft
The external message waits for approval
A required field is blank or two source systems disagree
An exception record with the conflicting values attached
No value is guessed and no key record is changed
A follow-up date has passed and no reply is recorded
A follow-up draft using the approved message pattern
A person reviews it before it is sent
The first approved write does not succeed. The workflow pauses, keeps the evidence, alerts a named owner, and resumes only after that person reconciles the records and authorises one controlled retry. If the target state cannot be confirmed, it stays paused.
Input
7:31 am
8 units are on hand. The approved reorder point is 12.
Check
7:33 am
The purchasing register contains no active request for SKU-042.
Decision
7:35 am
The rule allows a draft request for 24 units. It does not allow spending without approval.
Action
7:37 am
The request includes the item, quantity, synthetic estimated cost and the rule that triggered it.
Approval
7:47 am
The example owner approves the request. Until this point, nothing has been ordered or written back.
Writeback
7:50 am
The purchasing API rejects the request because a required order field is missing. No purchase order reference is returned, so the workflow records the error and pauses every dependent action.
Escalate
7:51 am
The exception keeps the approved request, source-record version, attempted payload, time, target response and workflow run ID together.
Reconcile
7:56 am
The owner confirms that no order exists, corrects the missing field and verifies that the source record, supplier, quantity and amount are unchanged, then authorises one controlled retry. A changed business value would require a new approval.
Verified writeback
7:58 am
The connector creates PO-7714, reads the reference back from purchasing and writes the confirmed reference and next check date to the ERP record.
This cross-system workflow record does not replace the failed attempt with a green tick. It shows the pause, the evidence sent to the owner, the human decision to resume and the final readback. A connected system may also provide its own activity history. Availability and coverage can vary by product, action, configuration and subscription.
| Time | Actor | Target | Action | Status |
|---|---|---|---|---|
| 7:31 | Digital employee | Inventory / SKU-042 | Read on-hand quantity and reorder point | Read only |
| 7:33 | Digital employee | Purchasing register | Checked for an open request | None found |
| 7:37 | Digital employee | PR-0092 | Prepared a purchase request with its reason | Waiting |
| 7:47 | Operations owner | PR-0092 | Approved the proposed spend | Approved |
| 7:50 | Digital employee | ERP / SKU-042 | Attempted the approved write; target rejected a required field | Paused |
| 7:51 | Digital employee | Operations owner | Sent the exception with record version, request, error and run ID | Owner notified |
| 7:56 | Operations owner | PR-0092 | Confirmed no target order exists, corrected the field and authorised one retry | Resume approved |
| 7:58 | Digital employee | Purchasing / PO-7714 | Retried once, read back the order and recorded the confirmed reference | Reconciled |
At 8:00 am the example run condenses the work into exceptions, pending approvals and completed actions.
All counts, record IDs, amounts, decisions and timestamps on this page are synthetic example data.
We first check what your existing systems and available connections can already do. If a real hand-off gap remains, the required access has been verified, and the written scope includes the connection, BestAI builds or configures a workflow-specific API connector for that gap. Before live data is connected, we agree what the workflow may read, what it may prepare, what always needs approval, and where each result is written back.
We will map the records, rules, exceptions, approvals and system connections before recommending what to build. We will also agree what counts as a failed or uncertain write, who is alerted, and what evidence they need before work resumes.