Loading

Creating a New User Input View

A user input view is built on a builder page that belongs to one datastore. The left half creates a new view; the right half lists the views that already exist over that datastore, with a button for each part of their configuration.

Where to find it

Architect Panel → Data:

  • Datastores — the datastore, then Table Designer, then the User Input Views button under its field list

Architect Panel → Forms:

  • User Input Views — the Forms entry for user input views

Before you start

Create the datastore and every field the form will collect. The builder lists the datastore's fields as they are when the page opens, and the stages you add later can only use fields that exist. Hidden system fields are not offered.

Creating the view

  1. Open the builder for the datastore. The page is headed User Input Views and shows the datastore's table name.
  2. Enter a View Name under Create New View. It is required, and it is what approvers and requesters see in headings and in automatically written e-mail subjects.
  3. Choose the Fields to Show. Every field starts ticked. Untick one and choose what happens to it instead: Remove from form, Obtain value dynamically using key (the field's row name, supplied by whatever page embeds the form) or Manually specify a fixed value, which reveals the field so you can set the value every submission will carry.
  4. Fill in the view's settings below the field list. These come from the view's own record, so new settings appear here as the platform gains them. The ones that matter most:
    • Security level (1 anyone, 2 signed in, 3 datastore permission) and the reCAPTCHA mode.
    • Reference number prefix and submit button text.
    • HTML shown above and below the form.
    • E-mail Address: how the requester's address is found, which every requester e-mail depends on. It is required.
    • Success action: what the requester sees after submitting. See Submission Success Actions.
    • Process Complete Action: required. Send an e-mail, run a custom function, or do nothing when the last stage approves.
    • Re-apply when declined: offers a declined requester an Apply again with my details pre-filled link, in the automatically written declined e-mail and on their tracking page. It needs an authkey field on the datastore. It is not offered after a time-out, and the tracking page does not offer it after a shortlisting decline.
    • Intake bindings: the fields that switch on application windows and capacity. Leave them blank unless you are setting those up; see Application Windows & Shortlisting.
  5. Optionally pick Copy Stages/Stage Actions to start from an existing process. It copies the stages and each stage's action buttons. It does not copy stage field assignments, visibility, e-mail settings or flag rules.
  6. Press Save User Input. The page refreshes and the new view appears under Existing Views.

The Existing Views panel

Each view shows its name, who created it and when, the field list, and a coloured status box: green when the view matches the datastore, blue when fields are missing or unassigned, red when it refers to deleted fields. Then, line by line:

  • Edit User Input View: edit the settings you entered at creation.
  • Multi-stage with Manage Stages: add and edit stages.
  • Once stages exist: Distributed Fields with Manage Stage Fields, Stage Field Visibility (Automatic or Manual) with Manage Field Visibility, Standard E-mails/Notifications and Additional E-mails/Notifications with Manage Settings, and Initial Stage Assignment with Manage Assignment.
  • Flag Rules (None, or a count of rules) with Manage Flag Rules.
  • View Form opens the live form in a new tab; View Requests opens the request list.

Standard E-mails/Notifications opens the six requester e-mail settings in one window: confirmation, approved/progress, completion, declined, request for more information and cancellation. Switch each on and optionally choose a template; with no template the platform writes the e-mail itself.

When the datastore changes

Adding a field to the datastore does not add it to existing views. The status box lists it under Missing fields with an Add Missing Fields to User Input View button. Deleting a field leaves the view pointing at it; Remove Deleted Fields from User Input View removes it from the view and from every stage field list.

Worked example

An IT team creates a datastore called equipment loans with fields for the borrower's name and e-mail, the item, the dates and a manager e-mail. On the builder they name the view Equipment Loan Request, untick a source field and give it the fixed value web, set security level 2, prefix EQ-, and point E-mail Address at the borrower's e-mail field. They choose Copy Stages/Stage Actions to start from their existing Stationery Request process, save, then use Manage Stage Fields to decide what the manager sees at stage 2.

Recommendations

  • Name views for the people reading them. The view name is in every automatic e-mail subject.
  • Set E-mail Address carefully. A wrong field there breaks every requester e-mail.
  • Use fixed values rather than visible fields for anything the requester should not choose.
  • Act on a blue or red status box straight away; a view out of step with its datastore misbehaves quietly.
  • Check the result in the Process Inspector once the stages are in place.