The Stage Fields system answers two related questions: which fields from your underlying datastore appear on the form (and at later stages), and who can see or edit each one at each stage. The default model is generous — every field on the datastore is shown — but real workflows usually want to be more selective.
A typical example: a purchase request has fields for supplier, items, total cost, and approval notes. The requester fills in supplier, items, and total cost. The line manager at stage 2 also adds an internal approval note. The CFO at stage 3 doesn't need to add anything but should see all of it. Stage Fields and the Stage Field Visibility Override layer together express this exactly.
Stage Fields — the main field-list
Once your UIV is saved, scroll to the Stage Fields sub-section. Here you list every field the form (or any subsequent stage) needs to show. Each entry binds one column from the datastore to a position in the form. Fields appear in the order you list them, so drag handles let you reorder them visually.
For each field you can configure:
- Whether it's editable on the initial submission form (stage 1).
- Whether it's editable at each subsequent stage individually.
- Whether it's visible at each subsequent stage.
- Which stage(s) it's required at (so a field can be optional initially but required at stage 3).
Note: Stage Fields control the form itself. A field can exist on the underlying datastore without appearing on the form — only fields you list here will be presented to users. This means you can use the datastore for backing data (created-by user ID, internal status flags, computed totals) without exposing those to the form, just by leaving them out of the Stage Fields list.
Stage Field Visibility Override
Use this when the default rules from Stage Fields aren't quite right for one specific stage. The override layer lets you express stage-specific exceptions without contorting your main Stage Fields setup.
Two examples where Visibility Override earns its keep:
Example 1: Cost Estimate visible to manager, hidden from final approver
On a purchase request UIV, you might want the Cost Estimate field visible to the line manager at stage 2 (they need to know the value) but hidden from the final approver at stage 3 (you've established a policy that final approvers shouldn't see the value to avoid anchoring bias). The main Stage Fields config marks the field visible by default; a Stage Field Visibility Override on stage 3 marks it hidden.
Example 2: Internal notes visible only at certain stages
An "Internal Notes" field that captures back-channel comments between authorisers should be visible at stages 2, 3, and 4 (where the authorisers are) but hidden at stage 5 (where the requester sees the final "complete" view). Set it visible by default, then add a Visibility Override on stage 5 to hide it.
Required at this stage?
A field can be optional on the initial form but required at a later stage. The classic pattern: the requester provides a justification (optional), and a manager at stage 2 is forced to attach a budget code (required at stage 2). Configure that by marking the field optional in Stage Fields and required at the relevant Stage Field Visibility Override row.
Required-at-stage is enforced when the stage's primary action is approve/progress. Decline and cancel actions don't enforce field requirements — declines can happen even if mandatory fields are blank, because the request is terminating rather than progressing.
Read-only at a stage
The visibility override has three states for any field at any stage: hidden, read-only (visible but not editable), and editable. Read-only is the right choice for fields the user shouldn't change but should see — typically the case for fields filled in by earlier stages.
Three examples:
- A "Supplier" field is editable at stage 1 (the requester picks the supplier), then read-only at every subsequent stage.
- A "Manager Note" field is hidden at stage 1, editable at stage 2 (the manager fills it in), then read-only at stages 3 and onwards.
- An "Internal Reference Code" field is hidden at stages 1 and 2, editable at stage 3 (Finance assigns it), then read-only at stage 4.
Common tips and gotchas
Three patterns that come up often:
Tip: Hide every field on a stage
If a stage's job is purely to acknowledge and move on ("I have seen this and approve it"), you can hide every field. The authoriser sees only the stage's HTML Data and the action buttons. Clean and minimal.
Tip: Use Display Format for computed visuals
If you want a stage to show derived information ("3 days overdue", "£1,250 over threshold"), don't add a backing column — add a Display-only field with a Display Format string that pulls together other field values.
Gotcha: Visibility Override always wins
If a field doesn't appear at a stage where you expected it to, the most common cause is a stray Stage Field Visibility Override row. The override layer always wins over the main Stage Fields config — that's by design, but it's worth knowing when debugging.