Build it with AI
Turn a repeatable business process into software built around the actual handoffs.
Create an application for stages, owners, records, actions, exceptions, and completion instead of coordinating the process manually.
Introduction
What a workflow application has to hold.
Most teams end up with a workflow application the same way: a process that lives in a document and is executed from memory. A remembered process runs well with the people who designed it. It degrades with every new participant, and the degradation is invisible because each person is doing what they were told rather than what the process requires.
The documented process and the executed process diverged some time ago, and nobody can say by how much. There is no state on the work item, no owner attached to the current step, and no rule preventing the transition that skips the check the process exists to perform.
What follows covers building a workflow application: the records it holds (work items, the states they pass through, owners per state, and the exceptions), the systems it reads (Slack and Google Drive), and what it does not fix.
The problem
A process that only exists in the sequence people remember.
Automation platforms model the trigger and the action and are weak on the state in between, which is where a business process actually lives. Checklists model the state and enforce nothing, so they document the process rather than running it.
The records are work items, the states they pass through, owners per state, and the exceptions, and the authoritative copy of most of them already lives in Slack or Google Drive. The checklist says step four is complete, the receiving team never got the handoff, and both are describing the same work item on the same day.
The cost is not the inconvenience: the process depends on one person knowing the parts that were never written down.
You're likely here because
- A new person learns the process by watching rather than by reading
- The documented process and the executed process diverged some time ago, and nobody can say by how much.
- When it is wrong, the process depends on one person knowing the parts that were never written down
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Stage-based workflow
- • Record views
- • Exception handling
Operated through Grow
- • Automated actions
- • Notifications
- • Follow-up
Systems it reads
- • Slack
- • Google Drive
- • Airtable
The record model
What a work item has to hold.
- State with an exit condition
- The state is only meaningful if what must be true to leave it is written down. Processes fail on this, and the failure presents as people not following the system.
- Owner of the current state
- Distinct from the owner of the item, which removes the gap where work sits between two people who each believe the other has it.
- Permitted transitions
- Enforced only where skipping causes real damage. Comprehensive enforcement produces comprehensive workarounds, generally in the first month.
- Required payload per transition
- What must accompany the handoff. This single constraint removes most of the class of failure where the receiving team gets an incomplete item.
- Exception path and its owner
- Modelled explicitly, because an unmodelled exception pushes people out of the system permanently rather than temporarily.
- Process version on the item
- So work in flight when the process changes stays interpretable, rather than being evaluated against rules that did not exist when it started.
- Elapsed time per state
- Which is where processes lose time, and it is invisible from either side of a handoff.
How it runs
From remembered sequence to enforced state.
Step 01
Describe what a workflow application has to do
Model the states a work item moves through and the exit condition of each. That model is the application; the interface is a rendering of it.
Step 02
Connect the systems of record
The systems holding the records the process acts on supply truth, and chat is where the handoffs get discussed. Reading both keeps the encoded process attached to what is actually happening.
Step 03
Build the operating surface
States, owners per state, permitted transitions, exception paths, and completion — as a running application rather than a diagram in a document.
Step 04
Start narrow
The one handoff that fails most, modelled as a state with an owner and a required payload. One enforced handoff produces more improvement than a complete process model that nobody follows.
Step 05
Route the exceptions
Work that falls outside the defined path goes to a named exception owner with context, rather than reverting to somebody working it out by message.
Step 06
Measure items completing without an undocumented manual intervention
Measure the share of items completing without an exception, and the elapsed time per state. Together they separate a process that is slow from one that is broken.
Implementation path
Encoding a process without freezing it.
- 01
Document how the process is actually run before modelling how it should be. The gap between the two is the specification, and the second version alone produces an application nobody uses.
- 02
Baseline elapsed time per handoff and the exception rate. Handoffs are where processes lose time and the loss is invisible from either side.
- 03
Model exceptions explicitly rather than treating them as failures. A process with no modelled exception path forces people out of the system exactly when the stakes are highest.
- 04
Run the encoded process in parallel for one full cycle. Cutting over on the strength of a design review is how a process application becomes shelfware.
- 05
Build the narrowest useful version first: the process as it is genuinely run today, encoded with explicit states and owners.
- 06
Documenting how the process is actually run — not how it is supposed to be — is a day or two of observation and is the specification. Modelling one handoff with a required payload is a week. Running it in parallel for a full cycle before cutover is what separates a used application from shelfware, and it cannot be compressed.
- 07
Once the worst handoff is enforced, add elapsed time per state to find where the process actually loses days, then model the second handoff. Full process coverage is rarely the right destination.
Controls
Controls that matter.
Control 01
Permitted transitions enforced, so the check the process exists to perform cannot be skipped by someone in a hurry
Control 02
An exception path with a named owner, because unmodelled exceptions push people out of the system permanently rather than temporarily
Control 03
The process version recorded on each item, so work in flight when the process changes can still be interpreted afterwards
Examples
Three handoffs that stop dropping.
The handoff that dropped
A required payload on the transition means the receiving team cannot be handed an incomplete item, which converts a recurring failure into a moment of friction at the point where it can be fixed.
The new starter’s third week
The process is readable from the system rather than absorbed by watching, which is the only version that survives the departure of the people who designed it.
The item nobody owned
An owner attached to the current state rather than to the whole item removes the gap where work sits between two people who each believe the other has it.
How it goes wrong
Three ways encoded processes get abandoned.
The design is based on how the process should work, and the application does not fit what people actually do.
Document the real process first and treat the gap as the specification. Building from the idealised version produces an application that is correct and unused.
No exception path exists, so anything unusual is handled by messaging and the system holds only the easy cases.
Model exceptions as first-class with a named owner. The exception path determines whether the system is used for the hard cases or abandoned for them, and the hard cases are where the value is.
The application is hard to change, and becomes the reason the process cannot change.
Version the process and record the version on each item. A process frozen by its own tooling is a worse failure than an unencoded one, and it takes longer to notice.
Limitations and considerations
What encoding a process makes visible rather than fixes.
- Encoding an unclear process makes the disagreement explicit and visible. That is genuinely valuable and it is not the same as resolving it, and the resolution is a management task rather than a build.
- A rigid process application handles the ninety percent and pushes the rest into workarounds. The exception path is what determines whether the system is used for the hard cases or abandoned for them.
- Processes change. An application that is hard to modify becomes the reason the process cannot change, which is a worse failure than the one it replaced.
- If the process genuinely differs every time, it is judgement rather than workflow and encoding it will fight the work. If the disagreement about what the process is has not been resolved, encoding it makes the disagreement visible and permanent.
- Connector coverage varies: Slack, Google Drive, Airtable are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build a workflow application with AI: common questions.
How is this different from a workflow automation tool?
Automation tools connect triggers to actions. A workflow application holds state between them — which item is where, who owns it now, what may happen next. That state is where business processes actually live, and it is what falls back into a spreadsheet when only automation exists.
What if the process changes?
Version it and record the version on each item, so work in flight remains interpretable. Processes that cannot change are a worse problem than processes that are not encoded, and this is the design decision that determines which you end up with.
Should every step be enforced?
Enforce the transitions where skipping causes real damage and leave the rest advisory. Comprehensive enforcement produces comprehensive workarounds, generally within the first month.
Which part of the process should be modelled first?
The handoff that fails most often. It is the highest-value state to model, the easiest to justify, and the one where a required payload produces a visible result in the first week.
What should the first version contain?
The process as it is genuinely run today, encoded with explicit states and owners. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure items completing without an undocumented manual intervention against the baseline taken before anything changed.
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build a workflow application around the process you actually run.
Model the handoff that fails most, enforce only the transitions that matter, and give the exceptions a named owner.