Answer Flags

Flag a request when an answer matters, tell the right person, route or hold it, and clear flags and release holds once reviewed.

Setting Up Flag Rules

A flag rule watches one answer on a user input view. When the answer matches, the rule raises a named flag on the request: it is recorded, shown to whoever handles the request, and can e-mail somebody, send the request to a different stage, or hold it until a person has looked. Use it for answers that matter, such as a declared medical condition, without anybody having to read every submission to find them.

Where to find it

Architect Panel → Forms:

User Input Views — Manage Flag Rules on the view, beside its Flag Rules count
Process Inspector — the Flags raised by the answers section

Flag rules work on any view, including one with no stages. If the builder shows no Flag Rules line, the feature is not installed on your system.

Writing a rule

Press Manage Flag Rules. The screen is headed User Input View - Flag Rules.
Set Flag Rules to Yes and fill in the first rule. Use Add Another Flag Rule for more.
Field Name: the field's row name on the datastore, not its title.
Comparison operator and value: the test. A yes/no question should be a tickbox field, which stores 1 for yes and 0 for no, so the test is equals 1.
Flag Name: what the flag is called everywhere it is shown, for example Medical / Allergies. Several rules may raise the same name.
Notify: who is told. Choose a field on the form, a custom function your developer provides, a static address, or the original requester (who must be signed in). Leave it unset to raise the flag and tell nobody.
Send From: the e-mail account. Required if anybody is notified; the platform never guesses one.
E-mail Template: optional. Without one the platform writes the message, with the view name, reference and flag name in the subject and the request's details in the body. In your own template, ##AMDATA/FLAGS## lists the flags on the request.
Send To Stage Number: optional. Sends a flagged request to this stage instead of where it would otherwise go. Stage 2 or above.
Hold The Request: tick to stop the next approver being told until somebody releases the hold.
Press Save Flag Rules.

Avoid testing a manual dropdown or radio list. Those store an internal number that differs between installations, not the words shown, so a rule written on one system may not match on another. Use a tickbox or a pills field.

When rules are checked

At submission, on the requester's answers.
At every stage approval, on what that stage's form collected. A question asked at a later stage can therefore raise a flag.
Not on a manual stage transfer by an administrator.
Every matching rule fires. Two different flags on one request are both raised.
Once per rule per request. A rule that matches again later raises no second flag and sends no second e-mail.

When consequences clash

Stage: the first matching rule that names a stage wins, and it beats Initial Stage Assignment. It can only move a request forwards; a rule that would send it back to an earlier stage is ignored and logged.
Hold: any matching rule asking for a hold holds the request.
Nowhere to go: on a view with no stages, or a rule matching at the last stage, the flag is raised and notified but the stage and hold are dropped.

What goes wrong

A rule never fires: Field Name is the title rather than the row name, or the field is not drawn on any stage so the answer never arrives. A rule naming a field the submission did not carry never matches.
A rule is skipped: it has no field, no flag name, or an operator that no longer exists. It is logged and ignored.
No e-mail: Notify is set but Send From is empty, or the recipient could not be resolved. The flag is still raised, and the request's progress page shows that its notification failed. A failure never stops the submission.

Worked example

A work-experience application asks Do you have any allergies or medical conditions? on its Data Collection stage, as a tickbox with row name medicalcond. The rule tests medicalcond equals 1, raises Medical / Allergies, notifies the static address of the occupational health team from the hub's account, and ticks Hold The Request. A student who ticks yes still gets their progress e-mail, but the placement supervisor is not e-mailed until occupational health has reviewed the application and released the hold.

Recommendations

Use tickboxes for the questions rules test.
Always set Send From when anybody is notified.
Hold only where review is needed; a hold stops the process until a person acts.
Grant Edit Existing to whoever must clear flags and release holds.

Reviewing, Clearing and Releasing Flags

Once a flag rule fires, the flag stays with the request until somebody deals with it. There are two separate actions: clearing a flag records that a person has reviewed it; releasing a hold sends a held request on to its approver. They are separate because I have read this and send it onward are different decisions.

Where to find it

Architect Panel → Forms:

User Input Views — View Requests on the view, then View Progress on the flagged request
Process Inspector — the rules that raise each flag

Architect Panel → Data:

Datastores — User Input View Flags, the record of every flag raised, for reporting

Where a flag is shown

The request's progress page: a Flagged box listing each live flag, the field and the value that raised it, whether its notification failed, and whether it is holding the request. A held request's box is red and says the request has not been announced to anybody.
The approver's decision page, above the request, from stage 2 onwards. It is not shown on the requester's own tracking page: a flag is an internal note about their application.
E-mails whose template contains ##AMDATA/FLAGS##. Automatically written approver e-mails do not include it.

Flags are not shown in the request list's Current Stage column.

Clearing a flag

Open the request's progress page.
Press Clear beside the flag's name.
Add a note if useful; it is stamped with your name.
Press Clear Flag. The flag is recorded as reviewed and stays on the record. Clearing does not release a hold.

Releasing a hold

A held request has been submitted, or approved at its current stage, but the next approver has not been told. The requester has had their confirmation or progress e-mail as normal.

Open the request's progress page. The Flagged box names the stage the request is waiting for.
Press Release Hold and Notify Approver and confirm.
The approver is e-mailed exactly as they would have been without the hold. Releasing does not clear the flags; clear them separately once reviewed.

Both actions need Edit Existing on the request's datastore. Without it, the box is shown but the buttons are not.

Holds and application windows

An application can be both queued in an application round and held by a flag. Shortlisting it still shortlists it, so it keeps its place, but the next approver is not told until the hold is released. A flag does not stop mattering because the round closed.

The flag record

Every flag raised is a row in the User Input View Flags datastore, with the view, the request ID, the flag name, the field and the value submitted, the e-mail result (0 none configured, 1 sent, 2 failed), the stage it sent the request to, whether it held the request, and when, by whom and with what note it was cleared. Use it to report on how many applications were flagged, and how quickly they were reviewed.

What goes wrong

A request held for weeks. Nothing reminds anybody about a hold. Check flagged requests routinely, or notify a mailbox that is watched.
A flag cleared but the request still stuck. Clearing does not release. Press Release Hold and Notify Approver.
The notification failed. The box says so. Fix the rule's recipient or sending account; the flag itself was still raised.

Worked example

An occupational health nurse receives a Medical / Allergies e-mail for application WX-3102, which is held. They open the progress page, read the declaration, and confirm the placement can go ahead with a note on the record. They press Clear with the note Reviewed, inhaler required, supervisor informed, then Release Hold and Notify Approver. The placement supervisor receives their approval e-mail a few minutes later.

Recommendations

Clear and release as two steps, in that order, so the record shows the review happened.
Write a clearance note whenever the review found something.
Report from the flag datastore to spot held requests waiting too long.
Give reviewers Edit Existing on the datastore, or they cannot act.