Loading

Overview of User Input Views

A User Input View (UIV) is a form over one of your datastores that turns each submission into a request and walks it through a series of approval stages. Use one whenever somebody submits something and one or more other people then have to approve it, decline it or ask for more information.

The person submitting needs no account if you allow it, and neither do the approvers: each approver is e-mailed a link that lets them act on that one request at that one stage.

Where to find it

Architect Panel → Forms:

  • User Input Views — build forms, their stages and their e-mails
  • Process Inspector — read how every approval process is configured, without editing anything
  • Application Periods — dated windows during which a form accepts applications
  • Shortlisting — decide who goes forward from a closed application round

Admin Panel → Processes:

  • Expiring Soon — requests that are about to time out
  • Process Inspector — the same read-only view, for administrators who are not architects
  • Shortlisting — the round console, for co-ordinators

The three Admin Panel tiles are visible to nobody until you grant each one to a security group. See Admin Panel.

How a request travels

  1. Stage 1 is the form itself. The platform calls it Initial Request. You never create it; the stages you add are numbered 2 and upwards.
  2. Submission writes the record to the datastore and sends the requester a confirmation e-mail, if you have switched that e-mail on. On a view with stages, the automatically written confirmation includes a link where the requester can track the request or cancel it.
  3. The request arrives at its first stage. Each stage has a Stage Action that runs on arrival: usually Send E-mail, which e-mails the approver a link to the decision page. A stage can instead start an identity check or require compliance checks first.
  4. The approver decides. Approve, decline, transfer to another stage or request more information, depending on which buttons you enabled for that stage.
  5. Approval at the last stage completes the request. The Process Complete Action then runs.

A request can also end because the requester cancelled it, or because a stage time-out declined it. Each outcome has its own tab on the request list, so declined, cancelled and timed-out requests are never counted together.

Who may submit: the security level

  • Level 1: anyone, signed in or not. The only level suitable for a public form. Consider reCAPTCHA (v2 Checkbox, v2 Invisible or v3).
  • Level 2: anyone who is signed in.
  • Level 3: signed-in users whose security groups have access to the datastore. The datastore permissions decide.

What you can build on top

  • Stages, fields and buttons: which fields each stage shows or lets the approver change, and which actions the approver has. See User Input Views.
  • Time-outs and reminders: chase an approver, chase a requester who has not supplied information, and decline, move or complete a request that has waited too long.
  • Answer flags: notice a particular answer, tell somebody, and optionally hold the request. See Answer Flags.
  • Application windows: accept applications only between two dates, queue them and shortlist when the round closes. See Application Windows & Shortlisting.
  • Running the requests: the request list and its tabs, a request's progress page, Expiring Soon and the approver's own list of links. See Managing Requests.

The timed work is done by scheduled tasks

Time-outs, approver reminders, information-request reminders, delayed stage e-mails and the closing of application windows are each done by a background task, and every one of those tasks ships switched off. A stage can carry a perfectly good time-out that never fires. Enable the tasks you rely on under Architect Panel → Automation → Tasks (see Tasks). The Process Inspector warns at the top of a process when a task it depends on is missing or switched off.

Worked example

A facilities team builds a Building Access Request over a datastore called access requests. The form is security level 2 so staff sign in, and the reference prefix is BA-. Stage 2, Line Manager Approval, e-mails the address held in the form's manager e-mail field. Stage 3, Security Office, e-mails a static mailbox and offers Approve, Decline and Request More Information. Stage 2 has a five-day time-out that declines, with a reminder after three days. The team enables the time-out and reminder tasks, opens the Process Inspector to confirm that neither task is reported as switched off, and grants Expiring Soon to the facilities security group so they can chase managers before requests lapse.

Recommendations

  • Build the datastore first. A view can only show fields that already exist on it.
  • Pick the security level deliberately. Level 1 is public; use it only for forms that are meant to be.
  • Enable the tasks you depend on and check the Process Inspector afterwards.
  • Grant the Processes tiles to the groups who run the requests day to day.
  • Use a reference prefix so requests are recognisable in e-mail subjects.