User Input Views

A User Input View — UIV for short — is a configurable, multi-stage form that captures data into one of your datastores and then routes the resulting record through a sequence of approval stages, with email notifications to the requester at every step. UIVs are how ActiveManage handles almost any workflow that boils down to "someone submits something, one or more people then approve or decline it".

If you've ever needed a form for purchase requests, leave applications, support tickets, change approvals, expense claims, document sign-offs, or onboarding checklists, a UIV is the building block to start with. The platform handles the form rendering, the data validation, the email sending, the timeouts and reminders, and the audit trail — you just configure the stages and templates.

What a UIV gives you

The full feature set is broad. At a minimum every UIV gives you:

• A public-facing form rendered automatically against any datastore, with field validation, optional reCAPTCHA, and configurable security levels.
• A unique reference number for every submission, with an optional prefix you choose (e.g. PR-1234, LEAVE/2026-001, TICKET-789).
• One or more stages after submission, each assignable to a different person or group, with its own visible field set and approve/decline/request-more-information actions.
• Automatic emails to the requester at every stage transition — confirmation, progress updates, completion, decline, cancellation, and more-information requests.
• Per-stage timeouts that automatically escalate or decline stuck requests, plus per-stage email reminders for authorisers (and for requesters when more info is requested back from them).
• A configurable success action when the form is submitted, and a separate Process Complete action for when the entire workflow finishes successfully.

Three real-world examples

To make this concrete, here are three very different UIVs and how they'd be configured:

Example 1: Purchase Request

A two-stage workflow. Requester fills in supplier, items, total cost, and reason. Stage 2 is manager approval (line manager signs off if cost < £1,000). Stage 3 is finance approval (CFO signs off if cost ≥ £1,000). Approved requests trigger a Process Complete Action that creates an order in the orders datastore.

Example 2: Leave Application

Single-stage workflow. Requester picks dates, leave type, and submits. Stage 2 is manager approval. Approved requests trigger a Process Complete Action that adds the dates to the team calendar. The Stage 2 has a 3-day timeout that auto-approves if the manager doesn't respond — a soft-default that fits team cultures comfortable with delegation.

Example 3: Customer Support Ticket

Open-ended workflow. Customer (security level 1, anonymous) submits a ticket. Stage 2 routes to triage. Stage 3 routes to whichever specialist team triage picked. Stage 4 is resolution confirmation by the requester themselves — they get a final "is this resolved?" email and click Yes/No. Tickets that loop back from stage 4 reset to stage 3.

The three security levels

Every UIV has a Security Level slider (1–3) that controls who can submit the form:

• Level 1 — Anyone can complete the form, even if they aren't logged in. Use for public-facing forms like "contact us", "report a problem", or anonymous tipping lines.
• Level 2 — Anyone who is logged in can complete the form. Use for self-service forms inside a customer portal where you want a paper trail tied to the user account but don't need fine-grained permissions.
• Level 3 — Only people who are logged in and have permission to write to the underlying datastore can complete the form. Use for internal-staff forms where access is governed by security groups.

Note: Level 1 forms are the only ones that work for anonymous public submissions. If you need to reduce spam on a Level 1 form, configure reCAPTCHA — the platform supports v2 Checkbox, v2 Invisible, and v3 modes. You'll need a reCAPTCHA account configured in Site Settings.

Where UIVs live in the admin panel

UIVs are managed under Architect Panel → Forms → User Input Views. From there you can create a new view, edit an existing one, configure its stages, manage its email templates, and preview the rendered form. The remaining articles in this section walk through each piece in detail.

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.

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.

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.

Stages are the heart of a User Input View. Each stage represents a checkpoint where the request can be approved, declined, or sent back for more information. Stage 1 is reserved for the initial form submission, so every stage you add starts at number 2 — that's a hard rule baked into the platform.

The stage system is genuinely flexible. A UIV can have two stages, three, five, ten — there's no hard limit. Stages can be assigned to different people, can show different fields, can offer different actions, can time out at different rates, and can each have their own per-stage messaging. The trick is choosing the right granularity for your workflow.

The fields on a stage

Every stage has the same configuration form. The fields are:

• Stage Number — must be a value of 2 or above as stage 1 is reserved for the form being submitted. Lower numbers run first. You can leave gaps (2, 4, 6) if you want room to insert stages between existing ones later without renumbering everything.
• Stage Name — shown to the authoriser and surfaced to the requester. Use clear, role-based names like "Manager Approval", "Finance Review", "IT Provisioning", "Final Sign-off".
• Stage Action — pick from a list that defines what the stage does. Most commonly it's a standard "approve / decline / request more info" set, but custom action sets are possible — see the Stage Actions article.
• Stage Timeout — optional. Configure the system to automatically decline the request or move it on if no response is received within a chosen time period. See below for how this pairs with reminders.
• E-mail Reminder — optional reminder email to the authoriser if they haven't responded within a chosen time period. See the dedicated Stage Email Reminders article.
• HTML Data (Top / Bottom) — extra HTML displayed above and below the request information when the stage is rendered to the authoriser. Useful for stage-specific instructions ("Please verify the supplier's tax registration before approving this stage").

How requests move through stages

When a submission arrives at a stage, the assigned authoriser sees the request information — the original form data, plus any stage-specific fields configured under Stage Fields — along with action buttons defined by the Stage Action setting.

Depending on what they pick:

• Approve — the request advances to the next stage (the one with the next-highest Stage Number).
• Decline — the request terminates as declined, the requester gets the Declined email, and the workflow stops.
• Request More Information — the request bounces back to the requester so they can revise. They get the Request More Information email; once they resubmit, the request returns to the same stage.
• Cancel — the request terminates as cancelled. Similar to decline but typically used for housekeeping (spam, duplicates, withdrawn requests).

Stage numbers don't have to be sequential

The order of stages is driven entirely by the Stage Number column, not by the order in which you create them. That's deliberate — it lets you:

• Reorder stages later by simply changing their numbers. No need to delete and recreate.
• Leave numerical gaps (2, 5, 8) so you can insert intermediate stages later without bumping every subsequent stage.
• Disable a stage temporarily by giving it a very high number and removing the stage above it from continuing on to it.

Multiple stages, multiple responsibilities

You can configure as many stages as you like. A typical small UIV has 2–3 stages; a complex multi-department workflow might have 6 or 7. Each stage is independent — it has its own assignee, its own timeout, its own reminder, its own visible field set, its own action buttons.

Three example configurations:

Two-stage simple approval

Stage 2: Manager Approval (approve/decline/request more info). That's it. Used for low-risk forms like leave applications, expense claims under a threshold, simple internal requests.

Three-stage tiered approval

Stage 2: Line Manager. Stage 3: Department Head. Stage 4: Finance/CEO sign-off. Used for higher-value requests where seniority of approval should match the value at stake.

Six-stage complex workflow

Stage 2: Triage. Stage 3: Specialist Review. Stage 4: Customer Confirmation. Stage 5: Implementation Team. Stage 6: QA. Stage 7: Final Customer Sign-off. Used for change-request workflows where multiple teams need to act.

Per-stage assignment

Each stage is assigned to a person or security group via the Stage Action's assignment configuration. The platform supports:

• Specific user — always the same person (e.g. one named line manager).
• Security group — anyone in the group can pick up the request (e.g. anyone in the Finance team).
• Computed from the request — assignee is derived from a field on the submitted form (e.g. "the requester's line manager").
• Round-robin — alternates between members of a group to balance load.

Tip: Computed assignment ("the requester's line manager") is often the right choice for org-wide forms. It scales without you having to add a new explicit stage every time the org structure changes. Combine with a fallback group if the computed assignee can't be resolved.

HTML Data per stage

The Top and Bottom HTML fields are an underused power feature. They render inside the stage view that the authoriser sees, around the request information. Use them for stage-specific guidance: legal disclaimers, links to relevant policy docs, side-by-side comparison data, or just a quick "things to check before you approve" reminder.

Warning: The HTML in these fields runs as raw HTML — the platform doesn't sanitise it (you're an admin, you're trusted). That means you can break the stage UI with bad HTML, and you should never paste in user-provided content without sanitising it yourself first.

Email reminders nudge the authoriser if a stage has been sitting in their queue without a response for too long. They're configured per-stage, so each step in your workflow can have its own reminder schedule and its own email template. That per-stage granularity is the key feature — you can be gentle on the first stage and firm on the final one, or vice versa, all without writing any code.

Turning reminders on for a stage

Open the stage's configuration and set E-mail Reminder to Yes. Two additional fields appear immediately:

• Time Period — how long the system waits before sending the reminder. You enter a number and pick a unit. The supported units are Seconds, Minutes, Hours, Days, Weeks, Months, and Years.
• E-mail Template — which template to use. If left blank, ActiveManage auto-composes a generic reminder. That's fine as a starting point but you'll typically want a bespoke template that matches your brand and tone.

Once turned on, the reminder fires once if the configured time period passes without the stage receiving a response.

Note: The time period is measured from when the request arrived at this stage, not from when the form was originally submitted. So a 2-day reminder configured on stage 3 fires 2 days after the request reached stage 3 — regardless of how long it took to get past stages 1 and 2.

Different reminders at different stages

Because reminders are configured per stage, every stage in your workflow can have its own cadence and its own template. Mix-and-match is the norm rather than the exception.

Three example configurations from real UIVs:

Purchase Request — 3 stages, increasing urgency

• Stage 2 — Line Manager Approval: reminder after 2 days, using a friendly template that says "You have a purchase request waiting for your review. Take a look when you get a moment."
• Stage 3 — Finance Review: reminder after 5 days, using a more formal template that mentions the request's age and the requester's contact details.
• Stage 4 — CFO Sign-off: reminder after 1 day, escalation-style — short, direct, with a note that the request has been waiting for executive approval.

Leave Application — single stage, lenient reminder

• Stage 2 — Manager Approval: reminder after 3 days. Many managers approve leave at the weekend so a same-day reminder would fire too soon.

IT Helpdesk Ticket — multi-stage, quick reminders

• Stage 2 — Triage: reminder after 1 hour. Triage is supposed to be fast.
• Stage 3 — Specialist Assignment: reminder after 4 hours.
• Stage 4 — Resolution: reminder after 1 day.

You're free to use the same time period across every stage if that's simpler — there's no rule that they have to differ. Consistency can be its own virtue when the UIV is used by many teams who each have their own expectations.

What happens after the reminder fires

The reminder email sends exactly once when the configured time period is reached. If the authoriser still doesn't act after the reminder, no further reminders go out from this setting — there isn't a built-in "second reminder" mechanism. For harder cut-offs use the companion Stage Timeout feature, which can automatically decline the request or move it to a different stage after its own configured time period.

Tip: Reminders and timeouts work well together. Set the reminder to fire well before the timeout deadline so the authoriser has time to act before the system intervenes. A common pattern: reminder at 50% of the timeout duration. So if the timeout is set to auto-decline after 7 days, set the reminder for 3 days — authorisers get a polite nudge with plenty of time to respond.

Reminder email contents

Reminder templates have access to the same merge tokens as other UIV email templates. Useful tokens include:

• ##REFNUMBER## — the request's reference number (with prefix).
• ##STAGENAME## — the name of the stage the request is sitting at.
• ##REQUESTURL## — direct link to the request's stage page so the authoriser can act with one click.
• ##AMDATA_fieldname## — any field from the submitted form. Use this to pull in the requester's name, the request summary, the value or amount, the requested date, or anything else that helps the authoriser act without opening the link.

Keep the template short and direct so it reads like a polite nudge, not a chase. A typical reminder is two short paragraphs: "Reminder that request ##REFNUMBER## is waiting at ##STAGENAME##. Please review when you have a moment: ##REQUESTURL##."

Multiple reminders per request lifecycle

Because every stage has its own independent reminder, a single request that travels through several stages can trigger multiple reminders over its lifetime — one per stage that exceeds its individual timeout. The requester might get nothing for the first three days (everyone acted within the reminder window), then a flurry of reminders if the request gets stuck at a later stage.

That's the right behaviour — the reminder is a signal to the authoriser, not the requester. If you want to also notify the requester at certain points, use the Approved/Progress email template at each stage transition or build a custom callback function for more specific notification logic.

The opposite direction from a standard stage reminder: when an authoriser picks the "Request More Information" action, the request reverses back to the requester. They're now the one holding the workflow up, and the platform can chase them in the same way it chases authorisers.

This article covers the initial more-info email plus the per-stage reminder behaviour that nudges the requester if they don't reply quickly. Both pieces are configured on the UIV and inherit the same reminder settings used for forward-direction nudges, but it's worth understanding the directional difference because it changes who you're writing the email to.

The initial "more info needed" email

The first message in the reverse direction is the Request More Information email, configured on the parent UIV itself (not on the stage). Open the UIV's main configuration and find the Request More Information E-mail setting; pick the template you want to use.

The template can use the standard set of merge tokens — reference number, requester's name, request URL — plus any field from the original submission via ##AMDATA_fieldname##. A well-written more-info email includes:

• A clear statement that more info is needed (in the subject line as well as the body, so the requester sees it before opening).
• What was already submitted, summarised — saves the requester from having to look it up.
• The specific question or clarification the authoriser asked. The platform's stage configuration includes a free-text notes field that authorisers fill in when sending back; that text appears in the email.
• A direct link back to the request (##REQUESTURL##) so they can edit and resubmit with one click.

If you leave the template blank, ActiveManage auto-composes a polite message asking the requester to revisit the form. That's a fine fallback but rarely as targeted as a custom template.

What the requester sees when they click through

The link in the email leads back to the original submission form, pre-populated with everything they originally submitted. A notes area shows the authoriser's question. The requester edits whatever's needed (or just clarifies in the notes area without changing anything else) and resubmits.

After they resubmit, the request returns to the same stage where the authoriser left off — not back to the beginning. The authoriser sees the resubmission in their queue with the updated values highlighted (where the data changed) and the new note from the requester.

Reminding the requester

Because the workflow is paused waiting on the requester, the system can also send them reminders if they don't act. These follow the same reminder pattern as the main Stage Email Reminders — they're per-stage, support seconds through to years as the unit, and use a chosen template.

Note: The same reminder configuration on a stage works in both directions. If the stage is waiting on the authoriser, the reminder is sent to the authoriser. If the stage is waiting on the requester after a more-info request, the reminder is sent to the requester instead. You don't need to configure them separately, but you might want to use different templates depending on who's being chased — the platform supports a separate reminder template specifically for the requester-direction case.

Best practice patterns

Three concrete suggestions for designing your more-info flow:

Keep the initial more-info email warm and specific

Reference what was submitted (using ##AMDATA_fieldname## tokens) so the requester knows exactly what part of their submission needs revisiting. Generic "please provide more information" emails are confusing — the requester opens them and isn't sure what's wrong.

Use shorter reminder intervals for requester-direction nudges

Requesters are more likely to have forgotten about a submission than authorisers are — they hit submit and moved on. A 24-hour reminder window is reasonable when chasing the requester; a 3-day window is reasonable when chasing the authoriser.

Build in a self-cancellation timeout

If a request genuinely gets stuck waiting on a requester who's gone quiet, use the Stage Timeout feature to auto-cancel after a longer threshold (e.g. 14 days). That way the request doesn't sit forever in the open queue — it's politely closed with a final email and an option to re-submit later.

Three real-world examples

Different UIVs benefit from different more-info flows:

• Customer Support Ticket: Initial more-info email is friendly ("We need one more detail to help you. Can you tell us…?"). Reminders fire every 24 hours up to 3 reminders, then the stage auto-cancels with a polite "we'll close this for now — please re-submit if you still need help".
• Internal Procurement Request: Initial more-info email is structured ("Finance has asked for: a) supplier tax ID; b) cost breakdown by line item"). Reminder fires once after 2 days. No auto-cancel — finance will chase by phone if the request goes stale.
• External Vendor Onboarding: Initial more-info email is formal ("Your application is in review pending additional information. Please log in and complete the following sections by the deadline below."). Reminders fire after 3, 7, and 14 days. Auto-cancel after 30 days with a re-application option.

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.

Two concepts work together to define what a stage does: Stage Actions define the buttons the authoriser sees and what happens when each one is clicked, while Stage Statuses are the human-readable labels that travel alongside the request so the requester (and anyone with read access) can see where it currently sits.

Get these two right and your workflow practically explains itself to users. Get them wrong and you end up with stuck requests, confused requesters, and authorisers who don't know which button does what.

Stage Actions

Each row in the Stage Actions section attaches one or more actions to a specific stage. The action set effectively defines the authoriser's options at that stage.

A typical configuration on a manager-approval stage might be:

• Approve — advances the request to the next stage. Sends the Approved/Progress email to the requester.
• Decline — terminates the request and sends the requester the Declined email. The request is marked as declined permanently.
• Request More Information — bounces the request back to the requester so they can revise their submission. See the Stage Information Request Reminders article for the flow.
• Cancel — cancels the request entirely. Suitable for spam, duplicates, or withdrawn requests. Distinct from Decline in that Cancel implies "shouldn't have been submitted" while Decline implies "reviewed and rejected".

You can add as few or as many actions as you like on each stage. A stage with no actions is unusual but valid — it'd be a pure read-only checkpoint that moves on automatically (e.g. when paired with a timeout).

Stage Statuses

Each Stage Status sets the label the request displays while it's at a given stage. "Awaiting Manager Approval", "With Finance", "In Triage", "Ready to Order" — short, descriptive, and ideally something the requester can read and understand without needing the platform's internal vocabulary.

When the authoriser actions a request and it moves on, the status updates automatically based on the next stage's status row. The status appears:

• On the requester's view of their own submission.
• On any browse view that lists submissions.
• In the email notifications the requester gets (as a merge token: ##STATUSNAME##).
• In the audit log.

Note: A request also has built-in overall lifecycle statuses — Submitted, Approved, Declined, Cancelled, More Information Required. The per-stage status configured here sits underneath those and gives the user finer-grained visibility into which stage the request is currently at. The two layers work together rather than replacing each other.

Stage Decline / Cancellation Notifications

If you need different email behaviour when a request is declined or cancelled at different stages, use the Stage Decline/Cancellation Notifications sub-section. There you can override the default Declined or Cancellation email template per stage, so a late-stage rejection can use a different message than an early-stage one.

Two examples of why you'd want this:

• An early-stage decline ("the request doesn't meet basic eligibility criteria") should be polite but quick. "Thanks for submitting; this didn't meet our requirements. Reasons attached. Feel free to re-submit if circumstances change."
• A late-stage decline ("the request was approved through 4 stages but the final sign-off declined") should be more detailed. "Your request was reviewed through every stage and ultimately declined at final sign-off. Here's the detailed reasoning. You can appeal by replying to this email or contacting your account manager."

Three worked-example workflows

Concrete configurations that show how Actions and Statuses fit together:

Workflow 1: Simple two-stage purchase approval

• Stage 2 — Manager Approval. Actions: Approve, Decline, Request More Information. Status: "Awaiting Manager Approval".
• Stage 3 — Finance Review. Actions: Approve, Decline. Status: "With Finance".
• Final state on completion: built-in "Approved" status. Status string shown to requester: "Approved — Ready to Order".

Workflow 2: Three-stage IT change request

• Stage 2 — Technical Review. Actions: Approve, Decline, Request More Information. Status: "Under Technical Review".
• Stage 3 — Change Advisory Board. Actions: Approve, Decline (with escalation note). Status: "At CAB".
• Stage 4 — Scheduling. Actions: Schedule (custom action that requires picking a date), Cancel. Status: "Scheduled — awaiting implementation".

Workflow 3: Customer support ticket with iterative back-and-forth

• Stage 2 — Triage. Actions: Assign to Specialist, Request More Information from Customer, Close. Status: "In Triage".
• Stage 3 — Specialist Investigation. Actions: Resolved, Need More Info from Customer, Escalate. Status: "Specialist Working".
• Stage 4 — Customer Confirmation. Actions: Confirmed Resolved, Still an Issue (loops back to Stage 3). Status: "Awaiting Customer Confirmation".

Every submission through a User Input View gets a unique reference number. By default this is the row's database ID — a plain integer like 1234. To make the reference recognisable across emails, dashboards, and conversations, you'll almost always want to prefix it with a short string of your choice.

Reference numbers turn up everywhere — in email subjects, on the request preview, in audit logs, in dashboards, in the support team's screen-share with a customer. A bare integer like "1234" gives no context ("which 1234?"); a prefixed reference like "PR-1234" is instantly recognisable as a purchase request.

Setting a prefix

On the UIV's main configuration form there's a Reference Number Prefix field. Whatever you type here gets prepended to every reference number generated by this UIV.

Common prefix patterns:

• PR- on a Purchase Request UIV → references look like PR-1234.
• LEAVE/ on a Leave Application → LEAVE/1234.
• SUPP- on a Support Ticket → SUPP-1234.
• 2026/CR- on a Change Request — includes the year, useful for annual numbering schemes → 2026/CR-1234.
• EXP-Q1- on Expense Claims grouped by quarter → EXP-Q1-1234.

The prefix can include letters, numbers, hyphens, slashes, dots, or any other characters that read cleanly to your users. Keep it short — three to seven characters works best, because the full reference shows up in email subject lines and link previews where space is tight.

Note: The prefix is applied at display time, not at storage time. The underlying database ID stays a plain integer, so internal joins and exports continue to work as if the prefix isn't there. Reports and SQL queries that filter on ID don't need to strip the prefix — they're working with the raw value, not the displayed one.

Where the reference appears

Once a prefix is configured, the reference shows up:

• In every UIV email's subject line and body, via the ##REFNUMBER## merge token in your templates.
• On the request preview when the requester or authoriser opens it — typically in a prominent position at the top of the page.
• In activity logs and audit trails — useful when investigating "what happened to request PR-1234?".
• In any browse view that lists submissions from this UIV's underlying datastore (using the datastore's Display Format setting).
• In the Reference Number field on the row itself, accessible via ##AMDATA_refnumber## if you want to embed it in document templates or external integrations.

Changing the prefix later

You can change the prefix at any time, but existing references will adopt the new prefix on next render — there's no historical separation. So if you change from PR- to PURCH/, the request that was previously visible as "PR-1234" suddenly becomes "PURCH/1234" everywhere, and any emails or links referencing the old format will look orphaned.

Three options to avoid that disruption:

Option 1: Don't change it

The simplest. Pick a prefix carefully at launch and leave it alone. This is the right answer for most established UIVs.

Option 2: Stop using the prefix entirely

Setting the prefix to blank reverts every reference to a plain integer. Numbers stay stable but you lose the recognisability. Useful if you're integrating with an external system that doesn't tolerate prefixes.

Option 3: Migrate with overlap

For high-importance UIVs where renaming is unavoidable, run the old and new prefix in parallel for a few months — emit both in emails, accept either when users reference them in support tickets. Eventually deprecate the old one. This is more work but avoids hard-cutoff confusion.

Three real-world examples

How different teams might pick their prefix:

Example 1: Small business — short and friendly

Internal-only UIVs for a 30-person company. Prefixes are 2–4 characters. PR-, EXP-, HR-, BUG-. Memorable and easy to say aloud.

Example 2: Enterprise — structured and unambiguous

Multi-department use across thousands of staff. Prefixes encode the issuing department, the type, and the year. FIN-2026-EXP-, HR-2026-LEAVE-, IT-2026-CHANGE-. Long but unambiguous in cross-team conversations.

Example 3: Customer-facing service desk — branded

Public support tickets surfaced to customers. The prefix is the brand name plus type. ACME-SUPP-, ACME-RMA-. Customers immediately recognise the brand in their inbox.

Tip: If you don't set a prefix, references will be raw integers like "1234". That's fine for internal-only UIVs but tends to confuse external requesters who get multiple emails about "#1234" and can't tell which system the reference belongs to. A prefix is the cheapest possible UX win.

The Success Action field on a User Input View decides what the requester sees the moment they hit Submit. It's a small choice but it shapes whether the form feels finished or feels like the requester is left wondering whether the submission worked.

The wrong choice can leave users confused ("did it work? do I refresh? do I wait for an email?"). The right choice closes the loop neatly and tells them exactly what to expect next.

The three options

Success Action is a Conditional Form field — picking an option reveals additional configuration specific to that option.

1. Show a thank-you message

Renders custom HTML on the same page where the form was. Best for keeping the user on-site so they can submit another request, browse related help, or just see a confirmation badge with their reference number.

The custom HTML can use any of the standard merge tokens — ##REFNUMBER##, ##AMDATA_fieldname##, etc. A typical thank-you message is something like:

<h2>Thank you, ##AMDATA_firstname##!</h2>
<p>Your request <strong>##REFNUMBER##</strong> has been submitted successfully.</p>
<p>You'll receive a confirmation email shortly. The first review typically happens within 2 business days.</p>
<p><a href="/page/myrequests">View all your requests</a></p>

2. Redirect to a URL

Sends the browser to any URL you specify after submission. Useful for sending the user back to a portal home page, a related self-service page, or a confirmation page with a richer layout than the inline thank-you message can support.

The URL can include merge tokens too — https://your-portal/requests/##REFNUMBER## redirects them straight to the detail page of their just-submitted request.

3. Run a custom function

Invokes a PHP function defined in customfunctions.php and shows whatever HTML the function returns. Use this when the success state needs to be computed at runtime — for example, picking a different message depending on the request type, or running custom logic before deciding what to show.

Example function:

function purchaseRequestSuccess($action, $formData, $AMuser, $AMDB) {
    if ($formData['total_cost'] > 5000) {
        return [true, [
            'html' => '<h2>Large request submitted</h2><p>Your request is over £5,000 and will be reviewed by both your manager and the CFO.</p>'
        ]];
    }
    return [true, [
        'html' => '<h2>Request submitted</h2><p>Your line manager will review shortly.</p>'
    ]];
}

This kind of conditional success message gives users a clear preview of what to expect, tailored to their actual submission.

Three real-world examples

Different UIVs benefit from different Success Actions:

Example 1: Public Contact Form

Success Action: Show a thank-you message. The message thanks them, gives the reference number, and explains the typical response time. Includes a link back to the home page so they don't feel stranded.

Example 2: Internal Leave Application

Success Action: Redirect to URL pointing at /page/myrequests. The user lands on their personal list of all leave requests, with the new one at the top with status "Submitted". They can see their whole leave history at a glance.

Example 3: Customer Support Ticket

Success Action: Run custom function. The function inspects the ticket type and severity. For low-priority tickets it shows a standard "we'll reply within 2 business days" message. For high-priority tickets it shows a "we've flagged this as urgent and you'll hear back within 1 hour" message. The exact message comes from the platform's per-tier SLA configuration.

Pairing with the Process Complete Action

The Success Action fires once, immediately after the requester submits the form. It's separate from the Process Complete Action, which fires once the request has been approved through every stage of the workflow.

A common pattern is to have both:

• Success Action: show a thank-you message with the reference number and a note about expected turnaround.
• Process Complete Action: trigger a custom function that creates a downstream record (for example, a finance entry once a purchase request has been fully approved, or a calendar event once a leave application has been approved through every stage).

Including the reference number

If you use the thank-you message option, you can include the reference number in the HTML using the standard merge token ##REFNUMBER##. This is the prefixed reference (e.g. "PR-1234") rather than the raw integer ID — so it matches what the user sees everywhere else.

Tip: A great thank-you message includes four things: a clear confirmation that the request was received, the reference number prominently displayed, an indication of who'll be reviewing it next, and a rough timeline. That single panel typically prevents 80% of follow-up "did you get my form?" emails to your support team.