Stages are the heart of a User Input View. Each stage represents a checkpoint where the request can be approved, declined, or sent back for more information. Stage 1 is reserved for the initial form submission, so every stage you add starts at number 2 — that's a hard rule baked into the platform.
The stage system is genuinely flexible. A UIV can have two stages, three, five, ten — there's no hard limit. Stages can be assigned to different people, can show different fields, can offer different actions, can time out at different rates, and can each have their own per-stage messaging. The trick is choosing the right granularity for your workflow.
The fields on a stage
Every stage has the same configuration form. The fields are:
- Stage Number — must be a value of 2 or above as stage 1 is reserved for the form being submitted. Lower numbers run first. You can leave gaps (2, 4, 6) if you want room to insert stages between existing ones later without renumbering everything.
- Stage Name — shown to the authoriser and surfaced to the requester. Use clear, role-based names like "Manager Approval", "Finance Review", "IT Provisioning", "Final Sign-off".
- Stage Action — pick from a list that defines what the stage does. Most commonly it's a standard "approve / decline / request more info" set, but custom action sets are possible — see the Stage Actions article.
- Stage Timeout — optional. Configure the system to automatically decline the request or move it on if no response is received within a chosen time period. See below for how this pairs with reminders.
- E-mail Reminder — optional reminder email to the authoriser if they haven't responded within a chosen time period. See the dedicated Stage Email Reminders article.
- HTML Data (Top / Bottom) — extra HTML displayed above and below the request information when the stage is rendered to the authoriser. Useful for stage-specific instructions ("Please verify the supplier's tax registration before approving this stage").
How requests move through stages
When a submission arrives at a stage, the assigned authoriser sees the request information — the original form data, plus any stage-specific fields configured under Stage Fields — along with action buttons defined by the Stage Action setting.
Depending on what they pick:
- Approve — the request advances to the next stage (the one with the next-highest Stage Number).
- Decline — the request terminates as declined, the requester gets the Declined email, and the workflow stops.
- Request More Information — the request bounces back to the requester so they can revise. They get the Request More Information email; once they resubmit, the request returns to the same stage.
- Cancel — the request terminates as cancelled. Similar to decline but typically used for housekeeping (spam, duplicates, withdrawn requests).
Stage numbers don't have to be sequential
The order of stages is driven entirely by the Stage Number column, not by the order in which you create them. That's deliberate — it lets you:
- Reorder stages later by simply changing their numbers. No need to delete and recreate.
- Leave numerical gaps (2, 5, 8) so you can insert intermediate stages later without bumping every subsequent stage.
- Disable a stage temporarily by giving it a very high number and removing the stage above it from continuing on to it.
Multiple stages, multiple responsibilities
You can configure as many stages as you like. A typical small UIV has 2–3 stages; a complex multi-department workflow might have 6 or 7. Each stage is independent — it has its own assignee, its own timeout, its own reminder, its own visible field set, its own action buttons.
Three example configurations:
Two-stage simple approval
Stage 2: Manager Approval (approve/decline/request more info). That's it. Used for low-risk forms like leave applications, expense claims under a threshold, simple internal requests.
Three-stage tiered approval
Stage 2: Line Manager. Stage 3: Department Head. Stage 4: Finance/CEO sign-off. Used for higher-value requests where seniority of approval should match the value at stake.
Six-stage complex workflow
Stage 2: Triage. Stage 3: Specialist Review. Stage 4: Customer Confirmation. Stage 5: Implementation Team. Stage 6: QA. Stage 7: Final Customer Sign-off. Used for change-request workflows where multiple teams need to act.
Per-stage assignment
Each stage is assigned to a person or security group via the Stage Action's assignment configuration. The platform supports:
- Specific user — always the same person (e.g. one named line manager).
- Security group — anyone in the group can pick up the request (e.g. anyone in the Finance team).
- Computed from the request — assignee is derived from a field on the submitted form (e.g. "the requester's line manager").
- Round-robin — alternates between members of a group to balance load.
Tip: Computed assignment ("the requester's line manager") is often the right choice for org-wide forms. It scales without you having to add a new explicit stage every time the org structure changes. Combine with a fallback group if the computed assignee can't be resolved.
HTML Data per stage
The Top and Bottom HTML fields are an underused power feature. They render inside the stage view that the authoriser sees, around the request information. Use them for stage-specific guidance: legal disclaimers, links to relevant policy docs, side-by-side comparison data, or just a quick "things to check before you approve" reminder.
Warning: The HTML in these fields runs as raw HTML — the platform doesn't sanitise it (you're an admin, you're trusted). That means you can break the stage UI with bad HTML, and you should never paste in user-provided content without sanitising it yourself first.