Creating a New User Input View

Creating a UIV is mostly a matter of working through the configuration form section by section. The form is long — over 20 fields — but only a handful are strictly required to get a working UIV. The rest are about tuning the experience and tying in email notifications. This article walks through the form in the order you'll actually fill it in, with notes about which decisions matter most.

Open the Architect Panel and click User Input Views under the Forms section, then click the green New User Input View button in the top-right corner.

1. Basics — what data is this form for?

The first block of fields binds the UIV to a datastore and gives it a name:

Table Name (Required) — the datastore the form captures into. Every field you intend to show on the form must already exist on this table, so create the datastore and its fields first if you haven't.
View Name (Required) — an internal name used in lists, references, audit logs, and default email subjects. Keep it descriptive: "Purchase Request", "Leave Application", "Building Access Request". Avoid generic names like "Form 1".
View Information (Required) — internal notes for your team. Not shown on the form. Use it to document why this UIV exists, who owns it, and any quirks future admins should know about.
Security Level (Required) — slide between 1 (anonymous), 2 (any logged-in user) or 3 (table-write permission required). See the Overview article for guidance on which to pick.

2. The submit experience — what does the form look like?

This block controls the rendered form itself — what's wrapped around the field list, what the submit button says, and whether reCAPTCHA is enabled.

Submit Button Text — defaults to "Submit" if left blank. Customise to match the action: "Send Request", "Apply for Leave", "Submit Ticket". A clear button label is one of the single highest-leverage usability improvements you can make.
HTML Data (Top / Bottom) — optional HTML rendered above and below the form fields. Common uses: an introductory paragraph explaining what the form does, terms and conditions, a privacy notice, a contact link for users who can't complete the form.
Reference Number Prefix — see the dedicated Reference Numbers article in this section. Short, recognisable prefixes (PR-, LEAVE/, TICKET-) make the references far easier to refer to in emails and conversations.
Enable reCAPTCHA? — Off, v2 Checkbox, v2 Invisible, or v3. Required for public Level 1 forms unless you're confident spam won't be an issue. The reCAPTCHA site/secret keys must be set in Site Settings.

Screenshot of the top half of the User Input View configuration form showing Table Name, View Name, Security Level, and Submit Button Text fields

3. Where notifications go — recipient email and templates

UIVs send up to six different email types as a request travels through the workflow. This block configures the sending account and the template for each.

The Recipient E-mail Address picker determines which mailbox the requester gets emails from. Then you choose templates for each notification type:

Confirmation E-mail — sent immediately after submission, confirming receipt.
Approved/Progress E-mail — sent at every stage that's been approved, until the final stage.
Completion E-mail — sent when the request reaches the end of the workflow successfully.
Declined E-mail — sent if the request is declined at any stage.
Request More Information E-mail — sent when a stage bounces the request back to the requester for more info.
Cancellation E-mail — sent if the request is cancelled.

If you leave any template blank, the platform auto-composes a generic message at send time. That's a reasonable starting point but you'll almost always want bespoke templates that match your brand voice.

Tip: Create one neutral "no-reply" sender account, then a tailored set of templates for each UIV. That way the requester sees consistent branding across every email but each specific form has the right tone. A leave-application confirmation can be warm and casual; a building-access decline should be formal and clear.

4. After submission — what happens once they hit Submit?

The Success Action decides what the requester sees the moment they click submit. There's a dedicated article on this with three options, plus three related fields:

Success Action — show a thank-you message, redirect to a URL, or run a custom function. See the Submission Success Actions article.
Initial Stage Assignment — who picks up the request at stage 2 (the first approver stage).
Process Complete Action — what happens once the request has been approved through every stage. Useful for triggering downstream actions like creating a finance entry, calling an external API, or sending a Slack notification.
Custom PHP Callback Function (Initial Form Submission) — the name of a function defined in customfunctions.php that you'd like to process the form data on initial submission. The function receives the form data as an array and can modify it, validate it, or trigger side effects before the row is saved. Used for advanced cases where the standard configuration isn't enough.

Screenshot of the Success Action dropdown showing the three options — Show Thank You Message, Redirect to URL, Run Custom Function — and the conditional fields that appear when Run Custom Function is selected

5. Save, then configure stages

Save the UIV. You'll then see additional sub-sections appear: Stages, Stage Fields, Stage Statuses, Stage Actions, and Stage Field Visibility Override. None of these can be configured until the parent UIV is saved, so always save first then dive into the stage configuration.

The next article in this section walks through stage configuration in detail.

Note: If you change the underlying Table Name after saving (rare but possible), every stage configuration is invalidated — they reference fields by name on the original table. Plan the table choice carefully up front.