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.
The example run reads only the records needed for this workflow. Each record below is synthetic.
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 same synthetic record, SKU-042, stays visible from its first check to the final writeback. This makes the decision and approval boundary inspectable.
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 approved purchase order reference and next check date are written back to the ERP record.
The action log is part of the workflow, not a separate promise. These entries show the synthetic SKU-042 trace.
| 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 | Created the approved order and recorded its reference | Written back |
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.
BestAI writes a custom integration program, also called an API connector, for each system the workflow needs. The exact connection depends on the tools you use. 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.