Submission
The form arrived with a company name, an ABN and a requested service.
- Input
- Company Northstar Advisory. ABN 83 614 220 918. Service: advisory onboarding.
- Output
- Run ON-2084 opened. State set to validation.
Workflow automation
Make the process explicit. Let the software move the work.
A workflow is a piece of work with a state, a dependency and a known next step. Some steps run. Some wait. Some try again. Some stop until a person decides. The failure mode PrimeLabs is hired to remove is a process that lives in inboxes, spreadsheets and one person’s memory.
A task, an automation, and a workflow are not the same thing
A task is one action: send this file, create this row, notify this person. An automation is that action running without someone clicking it, usually because a form was submitted or a clock reached a time. A workflow is the sequence those actions belong to, including the steps that are not automatic.
The difference shows up when something waits. An automation that fires and forgets cannot tell you that the client has not sent the document, that the approval is with a named person, or that yesterday’s API call failed and has not been tried again. A workflow can, because the current state is a record, not a guess reconstructed from email.
That is the commercial argument. Important work fails when responsibility, timing, dependencies and exceptions are spread across tools that were not built to hold a process. Custom workflow software makes the process observable. It does not promise that every step will run unattended.
Why a familiar process still stalls
One person knows the next step
If they are away, the work waits. The software should know the next step without asking them.
Status lives in inboxes
A forwarded thread is not a state. Two people can believe they are both, or neither, responsible.
A failed call disappears
The partner API times out. Nobody sees it. The customer thinks the request is still moving.
Approval is informal
“Looks fine” in a chat is not a decision you can show later, or reverse with a reason.
The same work is done twice
A retry, or a second person, creates a second account, ticket or payment chase.
Nobody can see where it stopped
Reporting then means reading the thread backwards and hoping the history is complete.
One run, with a state you can point at
This onboarding is an example, not a client project. Open a step to see what went in and what came out. The account step can be retried. The review step can be approved. Neither action leaves this page.
Example interface. Not a client project.
Onboarding #ON-2084 · Northstar Advisory
- Current state
- Human review
- Elapsed
- 2d 4h
- Previous step
- Document validation
- Next possible action
- Approve onboarding
Validate details
Required fields were present. The ABN matched the checksum. No person was needed.
- Input
- The submission payload.
- Output
- Validation passed. Next step: create the account.
Create account
The identity service timed out once. The same request was sent again and the account already existed, so a second account was not created.
- Input
- Create account for Northstar Advisory, reference ON-2084.
- Output
- Account NA-2084. The first call returned a timeout. The retry found that account.
Request documents
A request went to the client for the company extract. The workflow then waited.
- Input
- Account NA-2084. Required file: company extract.
- Output
- Request sent. State set to waiting on the client.
Await client
Nothing was held open overnight. The run resumed when the file arrived.
- Input
- Waiting for the company extract.
- Output
- File received. Passed to extraction. Elapsed time includes the wait.
Human review
Extraction finished and flagged an ABN that does not match the account. The run is waiting for a person.
- Input
- Extracted ABN 51 824 009 317. Account ABN 83 614 220 918.
- Output
- Exception open. Suggested route: compliance review. The suggestion has not moved the run.
Exception. ABN mismatch. The extract and the account do not name the same number. Review can approve, send it back, or stop the run. A model proposed the compliance route. It did not approve.
Provision service
This step calls the service that actually opens access. It does not run while review is open.
- Input
- Would receive account NA-2084 and the approved service list.
- Output
- No call has been made.
Notify client
The client is told only after provisioning succeeds, so a failed setup is not announced as complete.
- Input
- Would receive the provision result.
- Output
- No message has been sent.
Complete
Complete means every prior step has a recorded result, including the wait and the exception.
- Input
- The event history of ON-2084.
- Output
- The run is still in human review.
Long-running work needs a record, not an open request
Some steps finish in a second. Some wait overnight for a document, or for a week for an approval. Holding a web request open for that long is the wrong shape: the connection drops, the process restarts, and the wait is lost.
Durable state means the run is saved at each step. The software can sleep, resume when a file arrives or a person presses a button, and still know that it is the same onboarding. Elapsed time includes the wait. A crash does not erase the history of what already succeeded.
Business readers do not need the execution model. They need this outcome: the work has a current state on Tuesday morning, even though nobody had a screen open on Monday night.
A person is a step, not a failure of the automation
Human-in-the-loop is a design choice PrimeLabs keeps, not a gap to be closed later. A workflow should pause for review, approval, missing information, an exception, or a change that is expensive to undo. The pause is visible. It names who can move it, and what the allowed decisions are.
Automation supports that control. It gathers the context, checks the easy rules, and stops. It does not skip the gate because a model was confident, or because the queue was busy. In the example above, the ABN mismatch is the reason the run is waiting. Approving it is a deliberate action, and the example says so when you press it.
The same pattern fits approvals, contract changes, compliance review, payment follow-up and account changes. The list is a set of situations, not a claim that each one has already been delivered.
Failure should be visible, and a retry should be safe
A timeout, a rate limit or a brief outage is a transient failure. The step should be tried again, with a limit, and the attempts should be part of the history. If the retries run out, the run escalates: another system, or a person, sees that it stopped. Silent disappearance is the outcome to avoid.
Repeating a step must not duplicate the work. If the first call created the account and the response was lost, the next attempt should find that account rather than create another. That property is what engineers call idempotency. The practical test is simpler: doing it twice does not produce two records.
Manual review remains for the failures that are not transient. A rejected payload, a mismatch, or a permission error is not fixed by trying the same call again. The history stays either way, so a later report does not have to reconstruct the afternoon from memory.
Most workflows coordinate systems that already exist
The point is rarely to replace the CRM, the ledger, the payment provider, the mail system, file storage, the identity provider or a line-of-business API. The workflow calls them at the step that needs them, and keeps the state they do not keep: where this item is, who is waiting, and what happened last.
A webhook can resume a waiting run. An email can be one notification, not the system of record. A document workflow is often one stage inside a larger process: the file is requested, checked, and only then does provisioning continue. A customer portal can be the place the client sees that wait, without being handed the internal queue.
Which of those connections exist is a discovery question. Naming a system here is not a statement that it is already integrated.
Where Cloudflare fits, and where it does not
A workflow application can run on Cloudflare. It does not have to use every service, and this page is not a second tour of the platform. The selection rules live on Cloudflare application development.
- WorkersThe HTTP entry: a form post, a webhook, a button. Short work, then handoff.
- WorkflowsThe long run. Steps, retries, sleeps from seconds to days, and a wait until a person or another system sends an event. This is the usual home for the process itself.
- QueuesA slow or bursty side effect, such as a notification, taken out of the step that decided it.
- D1The queryable record: current state, the case list, the history a report reads.
- R2The files the run refers to. Not a substitute for the state.
- Durable ObjectsOnly when one identity needs a single consistent coordinator, such as a lock. Not the default store for every onboarding.
A model may propose the next action. It does not take it.
Inside a workflow, a model can classify an inbound request, extract fields, summarise the history, point at an exception, suggest a route, or draft the note a person will send. Those are proposals. The state machine stays in ordinary software: which step is current, which transition is legal, and whether a person is required.
A high-impact run does not advance because the model was confident. In the onboarding example, the mismatch is detected and a route is suggested. Approval is still a button. How that boundary is drawn in general is covered in AI application development.
The same shape, different work
Onboarding, approvals, contract changes, service requests, finance operations, payment follow-up, account changes, compliance review, data imports, provisioning, document processing, notifications, calls to an external API, and incident or remediation steps. Each can be a workflow when it has stages and a state worth keeping.
An internal business application often contains one of these as its queue. Workflow automation is the narrower claim: the movement of the item, including the waits and the failures, is itself the product. A custom web application is the larger frame when the same organisation also needs the screens, the roles and the reporting around that movement.
When a workflow application fits
Build it
- The process has several stages, and the order matters.
- Work waits on a person or another system.
- Failures need a retry and a place where someone can see them.
- Approval is part of the job, not an afterthought.
- More than one team needs the same status.
- Audit history matters after the item is finished.
- Volume makes manual chasing expensive.
- Existing systems have to be called in a defined order.
Leave it
- The task is one step, and nothing waits on it.
- A product you already pay for automates this well.
- The process itself is not agreed. Software would freeze the argument.
- Volume is too low to justify a custom run.
- The organisation is not ready to use one shared status.
Start from a single process that already hurts
A useful first note names the item, the stages, the step that waits, the step a person must own, and the system that must not be replaced. There is no account on this website.
Related
Straight answers
Is this the same as business process automation?
The phrase is broader. PrimeLabs means software that holds the state of a defined process and moves the item, including the steps that wait. It does not mean every repetitive click in the company.
Can a workflow be mostly human?
Yes. If the value is a shared status, a named approver and a history, the automated steps can be the small ones: validate, notify, record. The gates stay with people.
Will it write to our other systems?
Only where that write is specified. A first version can keep the run and leave the other system untouched until the exchange is clear.