None of this needs a consultant any more. Fields that hold real references, roles that resolve instead of naming a person, conditions on transitions, sub-tasks with rules that read across them - describing all of that correctly has been a specialist job with a rate card. Now you describe what you want in words and the assistant builds it, including the parts people skip because they are tedious.
A request, and what it is made of
A process starts with something somebody files: a request, an application, a claim, a report of a problem. That thing is a task, and it has fields.
The fields are typed the same way a spreadsheet's columns are, and it is the same set - which is wider than a form builder usually offers, because business forms need more than text and a dropdown.
A purchase request, for instance: the supplier as a value from the counterparty dictionary and not a typed name; the amount as currency; the cost centre as an actual org unit; the requester filled in automatically; urgency as a fixed set of choices instead of whatever somebody types; the invoice scan as an attachment; a linked record pointing at the contract it draws on; and a computed field for how long it has been open. A field can be required, validated against a rule, or read-only because it is derived - so what reaches the next person is what they actually need, not what somebody remembered to fill in.
Two field roles are worth calling out because they decide who does the work: a field can be marked as naming the assignee or a watcher. Fill in "responsible manager" on the form and that person is now a participant in the task, without anyone assigning it separately.
The route
A process is a set of statuses and the transitions between them. Draft, submitted, in review, approved, rejected, done - whatever the work actually has, in whatever shape it actually has it.
- Transitions can be conditional. A move is allowed only if the request meets the condition - under a threshold it goes one way, over it another. The condition is a structured rule, not code, and the platform checks it instead of trusting the person clicking.
- A transition can require approval. The task holds where it is until the decision is made, and the decision is recorded against the person who made it.
- A transition can wait for time. Nothing approved in three days moves on by itself - the timer belongs to the process, not to somebody's calendar.
- A transition can run work. The task holds in "processing" while something actually happens - a system is updated, a document is generated, a check is run - and moves on when it succeeds, or goes to an error status when it does not. That one is Automation.
A purchase request, with the parts people usually leave out drawn in:
Three of those arrows are the ones that get skipped when a process is drawn in a hurry: the way back to draft with a reason attached, the escalation when nobody answers, and the second approval that only exists above a threshold.
The statuses are yours, and real processes are rarely four boxes in a row. A support case runs new → triaged → in progress → waiting on the customer → resolved → closed, with a way back from resolved when the customer replies. An onboarding runs several tracks at once. A contract goes round the legal loop more than once before it goes forward. None of that has to be flattened into something tidier than the work is.
Processes inside processes
A task can have children, and that is how the shapes that actually occur get described.
Hiring one person is not one task: it is the offer, and under it the security check, the equipment request, the account setup and the first-day plan - each with its own owner, its own state and its own deadline. The parent is not done because somebody says so; a condition on its transition can read the children's own fields, so "close the onboarding" is only available once the things under it are actually finished.
Conditions can look up the tree as well as down - at the parent, at the children, at the root of the whole thing - so a sub-task can behave differently depending on what it belongs to. A check on a large contract is not the same check as on a small one, and it does not need a separate process to say so.
Who is responsible, and who is away
Roles are not a fixed list of three. A process declares the roles it actually has, and each one is resolved rather than written down.
- From the org structure. The approver is "the head of the requester's department" - who that is comes from the org data at the moment it is needed, and stays right when somebody moves department.
- From a field on the form. Whoever is named as responsible manager becomes the assignee; whoever is named as reviewer becomes a watcher. The person filling the request decides who is in it, within the rules.
- From a group. Anyone in finance may pick this up - the queue belongs to a team instead of a named individual who might be away.
- Several approvers at once. A decision can need more than one person, each vote recorded separately against whoever cast it, and not one signature standing in for a committee.
- Watchers who do not act. Some people need to see the request go past without being asked to do anything about it, and that is a role of its own, not an email to a distribution list.
Roles also decide what a person may do, not only what they must: who can edit a field, who can move a status, who can delete. That is per process, so a purchase request and a holiday request do not have to share a permission model just because they are on the same platform.
Delegation is built in. When somebody is away, their tasks resolve to their stand-in through the same layer that resolves roles - so the process does not have to be edited, and the work does not stop. A person's own list of tasks is filtered by their role in them: what I have to do, what I am watching, what is waiting on me.
Confidential fields
Some processes carry things not everyone in the route should read - salary on a hiring request, a medical reason, a commercial term.
Per-process field permissions can be switched on for exactly those. With them on, the rule is deny-by-default in both directions: a field cannot be written without an explicit grant, and its value is left out of what is returned to somebody without one. It is per process, not platform-wide, because most processes do not need it and paying for it everywhere would be a tax on the ordinary case.
Working the tasks
- A board by status - the queue as columns, with cards moved between them. It is a widget, so it can stand on a dashboard or a portal page next to the figures it explains instead of in a separate application.
- A list filtered by your role in the work - assigned to me, watched by me, waiting on me.
- The form itself, as a page of an app or a panel in a portal, so filing a request does not mean learning where the process system lives.
- Comments on the task, with
@-mentions that reach people through their own channel. - A history of what happened: what changed, when, and by whom - not reconstructed afterwards.
Answering from where people already are
This is the part that decides whether a process survives contact with the people in it.
A task notifies the person who has to act - through Telegram or email, whichever they use. And it works in both directions: a reply in the messenger, or a reply to the email, becomes a comment on the task, correlated back to it automatically. The approver who lives in Telegram and the supplier who only ever answers email both take part in the same process without either of them opening it.
And you do not need a consultant for it
Everything above is why process projects have historically needed one. Fields with real references, role schemes that resolve instead of naming people, conditions on transitions, a tree of sub-tasks with rules that read across it - that is a lot of machinery, and describing it correctly has been a specialist skill with a rate card attached.
Describe it in words instead. The assistant produces the whole structure: the task type and its fields, the statuses and the transitions, the conditions on them, the roles and who resolves to them, and the sub-tasks underneath.
A second effect matters more in practice. The assistant is not in a hurry, and it is not bored. The parts of a process that people skip are always the same parts: the rejection path, because everyone is thinking about the happy one; the timeout, because nobody wants to decide the number; the watcher role; the way back from "resolved" when the customer replies; the status that says what is actually happening while everyone waits. They are skipped because they are tedious and because the person building it has not seen enough processes to know they will be needed by March.
An assistant that has seen a great many of them puts them in, and then you take out what you do not want. That is the easier direction to work in, and the opposite of how these projects usually go.
How that works, and why the result is reviewable rather than something written into a live system, is AI in processes.
Next
Forms and records - the record itself: what a field can be, what it checks, and where the form opens.
Automation and orchestration - the half that runs without a person: triggers, the node palette, your own nodes, and scenarios that survive a restart.