# What you can do

> Requests with real fields, routes that resolve who approves from the org structure, boards to work them on, and the answer arriving from whichever channel the person actually uses

Source: https://aipril.dev/docs/processes/what-you-can-do

**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](https://aipril.dev/docs/spreadsheets.md) 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](https://aipril.dev/docs/processes/automation.md).

A purchase request, with the parts people usually leave out drawn in:

```mermaid
flowchart TD
    D["Draft"] --> S["Submitted"]
    S --> M["Manager approval"]
    M -->|"rejected, with a reason"| D
    M -->|"no answer in 3 days"| E["Escalated one level up"]
    E --> C
    M -->|"approved"| C{"Over the<br/>finance limit?"}
    C -->|"no"| O["Ordered"]
    C -->|"yes"| F["Finance approval"]
    F -->|"rejected, with a reason"| D
    F -->|"approved"| O
    O --> R["Received and closed"]
```

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](https://aipril.dev/docs/ai-organisation/people.md) 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](https://aipril.dev/docs/collab.md) 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](https://aipril.dev/docs/processes/ai.md).

## Next

[Forms and records](https://aipril.dev/docs/processes/forms.md) - the record itself: what a field can be, what it checks,
and where the form opens.

[Automation and orchestration](https://aipril.dev/docs/processes/automation.md) - the half that runs without a person:
triggers, the node palette, your own nodes, and scenarios that survive a restart.