> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Approval workflows

> Who must sign off on what, drawn as a chain — and where you go to find out one is stuck.

An approval does not enforce itself. Something has to say which action needs a witness, and who that
witness is. This is that something.

## Two screens

* **Approval workflows** — where a chain is built.
* **Workflow activity** — where you find out a chain is stuck, before somebody complains that it is.

## Building a chain

A workflow ties together three things:

| Part         | Answers                                                                                         |
| ------------ | ----------------------------------------------------------------------------------------------- |
| **Resource** | What kind of record this guards — a work order, an asset, a purchase request, a purchase order  |
| **Trigger**  | Which transition or action on that resource starts the chain — a status move, a submit, a raise |
| **Steps**    | Who must approve, in order, before the trigger's effect actually happens                        |

Each step names an approver by **role**, not by person — the same reasoning as
[notification audiences](/config/notifications#audiences): naming a person is what breaks the day
they leave. A step can also name more than one role, and say whether any one of them clears it or
all of them must.

## The chain is a graph, not a list

Drawn as boxes and arrows — a step per box, an arrow to whatever comes next — because a chain that
branches (three approvers under a threshold, a fourth above it) is a shape a numbered list cannot
show honestly.

* **Drag a box** to arrange the chain.
* **Draw an arrow** to send one step's outcome into the next.
* **Click a step** to set its approver role, and whether the chain continues on rejection or stops
  there.

Most chains are a straight line. The graph is only worth its screen space once a chain forks by
amount, category or site — a purchase request chain is the usual reason one does.

## Draft and publish

<Note>
  A workflow is versioned and published, exactly like [state models](/config/statuses) and
  [inspection templates](/config/inspections). A draft can be reshaped freely; a published version
  cannot, because live approvals are already running against it.
</Note>

Edit a live workflow and the edit lands on a new draft, not on the version chains are currently
running against. Publish that draft and new triggers start using it; a chain already in flight
finishes against the version it started on, so a change to the approver list never rewrites who
actually signed off on something already underway.

## Workflow activity

A monitor, not an editor. It exists so an admin sees what is blocked rather than discovering it when
the person waiting on it complains.

<AccordionGroup>
  <Accordion title="Needs attention">
    Chains that are stuck, overdue against however long a step is allowed to sit, or failed outright
    — a step whose named role nobody currently holds, the same failure mode
    [notifications](/config/notifications#the-third-failure-nothing-else-can-see) can hit, and for
    the same reason: the chain and the approver list both look fine on their own, and only the actual
    running instance shows that nobody can act on it.
  </Accordion>

  <Accordion title="Running">
    Every chain currently in progress, healthy or not, so you can see the shape of what is moving
    through approvals right now — not only the exceptions.
  </Accordion>
</AccordionGroup>

Each row names the workflow, the record it is guarding, which step it is sitting at, who that step
names, and how long it has sat there. Opening a row goes to the record itself — usually
[Approvals](/work/approvals) is where the actual decision gets made, by whoever holds the role the
stuck step names.

## Who can configure workflows

Building and publishing workflows takes the workflow administration permission — System
Administrator and Maintenance Administrator by default. See [roles](/setup/roles).


## Related topics

- [Approvals](/work/approvals.md)
- [Rules](/config/rules.md)
- [Purchase orders](/commercial/purchase-orders.md)
- [Purchase requests](/commercial/purchase-requests.md)
- [Lost & Found](/work/lost-and-found.md)