Loading

Reference Numbers and Prefixes

Every request has a reference: the record's ID on the datastore, with an optional prefix in front. A prefix such as BA- or PR/ makes it obvious which process a reference belongs to when it turns up in an inbox or a phone call.

Where to find it

Architect Panel → Forms:

  • User Input Views — the reference number prefix, set when the view is created or through Edit User Input View
  • Process Inspector — the prefix of every process, in the list and at the top of each one

How a reference is made

The reference is the prefix followed by the record ID: a view with prefix BA- shows record 1234 as BA-1234. Nothing extra is stored on the record. The prefix is added whenever a reference is displayed, so:

  • the number is unique within the datastore, because it is the record ID;
  • two views over the same datastore with different prefixes show the same record under different references;
  • changing the prefix changes every reference the view displays from then on, including on old requests. E-mails already sent keep the old form.

Where the reference appears

  • Automatically written requester e-mails: the subject is the view name followed by the reference in square brackets, for example Building Access Request [BA-1234]. With no prefix it reads [Ref No. 1234]. Automatically written approver e-mails are different: they are headed [ACTION REQUIRED] with the view name, your site name and the stage name, and carry no reference in the subject.
  • The request's progress page: headed with the view name and the reference.
  • Shortlisting and Expiring Soon: in their Ref columns.
  • Flag notification e-mails: in the subject, beside the flag name.
  • The requester's Your Requests page: each entry is headed Request and the reference.

The approver request list shows the bare record number, without the prefix.

Using it in your own templates

There is no single tag for the prefixed reference. Type the prefix into the template and follow it with ##AMDATA_ID##, which inserts the record ID: BA-##AMDATA_ID##. If you later change the prefix, update the templates too, or the e-mails and the screens will disagree.

Setting the prefix

  1. On the builder, under Existing Views, press Edit User Input View for the view (or set it when creating a new one).
  2. Enter the prefix in the reference number prefix setting. Include any separator you want, such as a hyphen or slash; nothing is added for you.
  3. Save, then search your e-mail templates for the old prefix and update them.

What goes wrong

  • A reference quoted by a requester is not found. Search the datastore by the number after the prefix; the prefix is not stored.
  • Templates show a different prefix from the screens after a change. Templates hold typed text; update them.
  • Two processes share a prefix. The same number may then mean different records in different datastores. Give each view its own.

Worked example

An organisation runs three processes: building access, equipment loans and purchase requests. It gives them the prefixes BA-, EQ- and PR-. Its custom confirmation templates read Your request BA-##AMDATA_ID## has been received. When the service desk takes a call about EQ-512, they know which process it belongs to and open record 512 in the equipment loans list. A year later the purchase prefix changes to PO-; the architect updates the view and the two purchase templates the same afternoon.

Recommendations

  • Set a prefix on every view, short and distinct.
  • Include the separator in the prefix itself.
  • Decide the prefix before go-live; changing it later rewrites every displayed reference.
  • Keep templates in step with the prefix.