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.