Loading

Stage Fields and Visibility Rules

Two screens decide what each person in a process sees. Stage field assignment says which fields are filled in at which stage; the visibility override says whether a field filled in earlier is shown, hidden or editable again at each later stage.

Where to find it

Architect Panel → Forms:

  • User Input Views — Manage Stage Fields and Manage Field Visibility on the view (shown once it has stages)
  • Process Inspector — each stage's Fields shown at this stage table

Assigning fields to stages

Manage Stage Fields opens Form Stage Field Assignment. It needs at least one stage; with none it says You haven't set up any stages yet.

  1. The User Input View Developer tree on the left has one branch per stage, starting with stage 1, the form itself. Available Fields on the right lists the view's fields.
  2. Drag each field into the stage where it should be filled in. Stage 1 is what the requester completes; a field placed at stage 3 is completed by the stage 3 approver.
  3. Order fields within a stage as you want them drawn.
  4. Press Save Form Stage Information.

Until any field is assigned, the builder shows Distributed Fields: No and every field is drawn on the form. Once you assign fields, a field that is not assigned anywhere is listed under Unassigned Fields in the view's status box and is not drawn.

Showing earlier answers at later stages

Manage Field Visibility opens Form Stage Field Visibility Override: a grid of fields down the side and stages across the top.

  • Blue pencil: the stage the field is assigned to. It is editable there; you cannot change that here.
  • Grey crossed eye: a stage before the field is filled in. Nothing to show.
  • Eye: at a later stage, the field is shown to that stage's approver, read-only. Click to switch it to hidden.
  • Pencil beside the eye: also let that later stage change the value.

Press Save Visibility Information. The builder then shows Stage Field Visibility: Manual; with no overrides saved it reads Automatic, and later stages see what earlier stages filled in.

What these screens do not do

  • Whether a field is required comes from the field's own definition on the datastore, not from the stage. There is no per-stage required setting.
  • Questions asked when an approver presses a button, such as a decline reason, are not datastore fields. They are set on the Form Stage Actions screen, stored against the decision rather than on the record, and listed in the Process Inspector under Also asked for.
  • Hiding a field here is not access control. Anyone who can open the record in the datastore can still read it. Use field permissions for that.

What goes wrong

  • A field missing from every stage after you start assigning is never collected. Check the Unassigned Fields list.
  • A field that a later setting depends on is not drawn. An intake start-date field, a flag rule's field or a delayed e-mail's date field must be on a stage, or the submission never carries it. The Process Inspector checks the intake case.
  • A field deleted from the datastore shows as DELETED FIELD; use Remove Deleted Fields from User Input View on the builder.

Worked example

A purchase request has fields for supplier, items, cost, a budget code and a finance note. Stage 1 collects supplier, items and cost. The architect assigns the budget code to stage 2 (Line Manager) and the finance note to stage 3 (Finance). In the visibility grid, cost is visible at stages 2 and 3; the budget code is visible and editable at stage 3 so Finance can correct it; the finance note has no later stage. The Process Inspector then lists, for each stage, which fields the approver can read and which they can change.

Recommendations

  • Assign every field once you start distributing, or it silently stops being collected.
  • Keep approver stages short. Show what they need to decide, not the whole record.
  • Use field permissions for genuine confidentiality, not visibility.
  • Re-check after datastore changes using the builder's status box.