# Stages: the part of the form that happens after you submit it

Canonical: https://useformwork.com/blog/introducing-stages

FormWork forms now have a process: stages with owners, due dates and actions, approvals by link, and My work. Why we built it this way.

For most of FormWork's life, the interesting part ended at the submit button. We put years into what happens before it. After it, you got a row in a table and whatever automations you'd wired up.

That isn't how people with demanding forms think about them. They're buying the process behind the form: a request comes in, someone reviews it, a decision is made, and emails, documents and records follow.

Now, every form can have a process. Entries move through stages, each stage can have an owner, a due time and buttons that move the entry on, and approvals work by email link for people without a FormWork account. This post is about why it looks the way it does.

## The half we hadn't built

You could build an approval process in FormWork before this. I built several: a Status dropdown as a team field, a team button to change it, and an automation with a condition to send the right emails.

It worked in a demo. It didn't hold up when a real team used it for a month.

Nobody could answer the questions a team actually asks. Who has this one? How long has it been sitting there? Who changed it to Approved, and why? Status was a value on the entry, and a value doesn't know who owns it or when it's due.

When we planned the fix, the first draft made "stage" a new kind of team field. Talking it through, that was the wrong shape. A stage isn't something you know about an entry. It's where the entry is. So stages became part of every entry, with their own history.

## What a stage is

A process is the set of stages a form's entries move through, such as New, Waiting for approval and Done. You build it on the **Process** tab in the builder, next to the fields and automations.

Each stage is **Open** (the team is working on it), **Waiting** (for an approval, or for someone outside the team) or **Closed** (finished, with no owner or due time).

The process goes live when you publish the form, and publishing checks it: every open or waiting stage needs a way out, and there has to be at least one closed stage. I'd rather the builder refuses to publish than have entries pile up in a stage nobody can leave.

Like automations, every entry follows the latest published process, whichever version of the form it was submitted on. A process is how your team works now, not part of the record. Add an action to a stage and entries already sitting there get the button. Remove a stage that still has entries and the publish review asks where they should go.

## Owners and due dates

A stage can give each entry an owner when it arrives: a person, a group, the person in a team member field, or whoever owned it before.

Groups were the interesting bit. An entry owned by the Purchasing group is unassigned within it until someone takes it. When they do, it stays in the group too, so it doesn't vanish from the team's view the moment one person picks it up.

A due time is set in hours, days or weeks. Days keep the time of day in your account's timezone, so an entry that arrives on Tuesday at 14:00 and is due in 2 days is due on Thursday at 14:00, even across a clock change. Overdue entries show in red wherever they appear.

One thing we deliberately don't do: FormWork doesn't email anyone when an entry is assigned to them or goes overdue. Every team wants that differently. The **In a stage too long** trigger, or the **Remind the owner when a stage is overdue** template, does it in a way you can see and change.

## Actions

Actions are the buttons that move an entry on: **Send for approval**, **Approve**, **Mark as done**. Each says which stage it moves to, whether it asks for a comment, who can use it and, optionally, a confirmation question.

Actions you can't use aren't hidden. They sit under **More actions** with the reason: "Only the owner can use this". Hidden buttons generate support questions. Explained ones mostly don't.

After a move you get **Undo** for a few seconds, but only if the move started no automation and sent no approval requests. We can put an entry back in its old stage. We can't unsend an email, and I didn't want an Undo button that lies.

## Approvals, for people who will never log in

This is the part we spent longest on.

A waiting stage can need approval. You choose who's asked: a person, a group, the person in a team member field, a fixed email address, or an address the respondent gave on the form. You choose whether any one approval is enough, everyone must approve, or at least a number of people. And you choose where the entry goes when it's approved, rejected, or when the links run out.

Approvers get an email with **Approve** and **Reject** buttons, and they don't need an account. The person signing off a purchase is often the person least likely to have one, and asking a finance director to create a login to approve one desk is how processes end up back in email threads.

Each link is for one person and one entry, works once and expires, and approvers only see the answers you choose to show them.

Rejecting always needs a comment. "Rejected" with no reason starts an argument rather than ending one.

## People never pause an automation

The obvious way to build approvals is an automation step that pauses until someone clicks. Our own plan said we'd look at exactly that once there was evidence it was needed.

The trouble is where the state ends up. While the run is paused, the fact that a request is waiting for Finance lives inside the run. You can't filter by it, you can't hand it to someone else, it can't be overdue, and editing the automation leaves you deciding what to do with every paused run.

So the work is split into three layers, and each waits in its own way:

| Layer | What it does | How it waits |
| --- | --- | --- |
| Form logic | Calculations, defaults, visibility and validation while someone fills in the form | Never |
| Automations | Emails, documents, records and other systems, from start to finish | Only on time, with a Wait step |
| Stages | Where each entry is, who owns it, what happens next and who approves | The entry waits in a stage |

Automations never wait for a person. People act on stages, and stages start automations.

So "if the total is over £500, ask Finance, otherwise approve it" is an automation: **Form is submitted**, an **If**, and a **Move to stage** in each branch. "When it's approved, create a purchase order and email it" is another, started by **Stage changes**. "Remind the approvers after 2 days and ask the head of Finance after 4" is the **Remind and escalate approvals** template.

Moves made by automations can start other automations, which is how you build a loop by accident. FormWork spots an entry being bounced around and stops the chain, and the runs it stopped tell you why.

## My work

Owners and approvals only help if people can find what's theirs. **My work** is one list across every form in the account: approvals waiting for you, then overdue entries, then entries you own, then unassigned entries in your groups.

Each row has one button for the obvious next step, such as **Approve** or **Assign to me**, and the whole list works from the keyboard. On a good morning you can clear a queue without touching the mouse.

## Telling the person who asked

Respondents can follow their request on a read-only status page, if you turn it on. It's off by default, and should stay off for things like hiring decisions and complaints.

They see a label you write for each stage, such as "Being reviewed", never your stage names, owners or comments. Publishing is blocked if anything internal about a stage would be shown to them.

## What we didn't build

- **A board view.** Instead there are stage filters with counts above the entries table, plus quick filters such as **Assigned to me** and **Overdue**. A board is a later project.
- **Parallel branches.** An entry is in one stage at a time. We aren't building a general process engine, and an approval where everyone must approve covers the common case.
- **Business hours and holidays.** Due times and waits count calendar time.
- **Stages on data tables.** Only forms have a process.

Each of these makes the model harder to explain, and I'd rather ship something a team understands on the first afternoon.

## How to start

Open a form in the builder, select **Process**, and choose **Review and approve** under **Start from a template**. It gives you New, Waiting for approval, Approved, Done and Rejected, with actions to move between them.

The waiting stage starts with **Approve** and **Reject** as plain actions, so your team can decide inside FormWork straight away. To ask people by email, turn on **Needs approval** on that stage and add approvers.

If you built the Status field version I described at the start, the Process page offers **Turn Status into stages**. Each option becomes a stage, entries move into the matching one when you publish, and it lists the automations that use the old field.

The docs have the detail:

- [Stages](/docs/process/stages)
- [Owners and due dates](/docs/process/owners-due-dates)
- [Approvals](/docs/process/approvals)
- [My work](/docs/process/my-work)
- [Respondent status](/docs/process/respondent-status)
- [Automation triggers](/docs/automations/triggers) and [steps](/docs/automations/steps)

If you try it on a real process and something doesn't fit, I'd like to hear about it. That's how the last version of this got replaced.

— Andrius