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 likePR-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.