Managing Requests

Run user input view requests day to day: the request list and its tabs, a request's progress page, Expiring Soon, the Process Inspector and approvers' links.

The Request List and Its Status Tabs

Every user input view has a request list: the records its form has created, with a strip of tabs across the top that counts and filters them by where they stand. It is the working list for whoever runs the process day to day.

Where to find it

Architect Panel → Forms:

User Input Views — View Requests on the view opens its request list

Admin Panel → Processes:

Expiring Soon — where the Timing Out Soon tab leads

The tabs

Each tab shows its count in brackets and filters the list when clicked.

Active Requests: requests still in progress, judged by the most recent thing that happened to each: waiting for a stage's decision, or sent back to the requester for information. This is the default tab.
All Requests: every live record in the datastore, whatever its state.
One tab per stage, named after the stage: requests waiting for that stage's decision.
Waiting For Information: requests sent back to the requester.
Declined Requests: declined by an approver.
Cancelled Requests: cancelled by the requester.
Timed Out Requests: declined by a stage time-out. It has its own colour so it is not mistaken for Declined.
Timing Out Soon: requests that will time out within the warning window. It opens the Expiring Soon screen rather than filtering the list, and is drawn only for people who have been granted Expiring Soon.
Completed Requests: approved at the last stage, by a person or by a Complete Request time-out.

The list also has a Current Stage column: the stage name for a request in progress, or Waiting for Information, Declined, Cancelled, Timed Out, Moved Stage or Completed.

Why the counts may not add up

Active and the stage tabs ask different questions. Active looks at the latest event; the stage tabs look at the furthest stage reached. A request sent back for information after reaching a later stage can appear in both.
All Requests counts records, including any created outside the form.
Timing Out Soon looks ahead and never includes something already overdue; that has either timed out already or is waiting for the time-out task to run.

Using the list

Open the list with View Requests.
Start on Active Requests, or a stage tab if you look after one stage.
Open a request with its View Progress row action to see its history, its e-mails and the actions you can take. See Working a Request from Its Progress Page.
Check Timing Out Soon regularly if your stages have time-outs, and chase or pause what is about to lapse.
Use Timed Out Requests to review what lapsed, separately from what was refused.

There is no batch approve or decline. Each request is decided on its own page, so every decision sends the right e-mails and runs any flag rules.

Where the window comes from

Timing Out Soon uses the Days ahead to warn about time-outs setting, in the Stage Time-outs group under Architect Panel → Configuration → Site Settings. It defaults to 14 days. See Site Settings.

What goes wrong

No Timing Out Soon tab. You have not been granted the Expiring Soon tile. Ask for it to be granted to your security group.
Finished requests stuck in Active. The last stage is a page nobody approves. Give it a Complete Request time-out.
A stage tab count that looks one stage out. Each stage tab counts requests waiting for that stage, which have already been approved at the stage before.

Worked example

A work-experience co-ordinator opens the applications list each morning. Active Requests shows 41; the Placement Supervisor tab shows 12 waiting on supervisors; Waiting For Information shows 3 students who have not replied; Timing Out Soon shows 4. They click Timing Out Soon, chase the four supervisors from Expiring Soon, then check Timed Out Requests for anything that lapsed overnight before reporting the week's refusals from Declined Requests alone.

Recommendations

Grant Expiring Soon to whoever works the list, so the tab appears.
Report time-outs separately from declines.
Complete page-only last stages with a time-out so Active stays meaningful.
Work from stage tabs when different people own different stages.

Working a Request from Its Progress Page

Each request has a progress page for the people who run the process: its stage history, what every approver recorded, every e-mail it has generated, and the corrective actions an administrator can take when a request is stuck.

Where to find it

Architect Panel → Forms:

User Input Views — View Requests on the view, then View Progress on a request

Admin Panel → Processes:

Expiring Soon — the Open button on a request

You need Read on the request's datastore to open the page, and Edit Existing to use the buttons that change a request.

What the page shows

A heading with the view name and the reference.
The progress bar, one step per stage. The stage the request is waiting at reads Current Stage; an application held in a closed-window queue reads Awaiting shortlisting instead, because nobody has been asked yet.
The request's details.
A Waiting for Information box when the requester has been asked something and has not answered, saying which stage asked and when.
A Flagged box when answer flags were raised, listing each flag, the answer that raised it, whether its notification failed, and whether it is holding the request.
Per-stage records: Approval Fields, Decline Fields and Stage Move Fields hold the answers approvers gave when they pressed a button, and any information requests and responses.
E-mail Correspondence: every e-mail the request has sent, with Recipients, Subject and Date/Time Sent, and the message itself.

The buttons

Action Request (with the waiting stage's name) opens the approver's decision page in a new tab. Whatever you press there is recorded as that stage's decision, so use it only when you are entitled to decide.
Edit Details opens the record for editing.
Rollback to Previous Stage removes the last stage decision and sends the request back. You must enter a Number of days to exclude from automatic timeout (1 to 365, default 7) so the request is not timed out the moment it returns. On a Verify Identity stage the button reads Reset Stage.
Close Information Request appears while the request waits on the requester. Record the information received, or why it is no longer needed; leave E-mail the approver ticked to send them a fresh link. The stage does not move and the decision stays with the approver.
Clear on a flag records that it has been reviewed; Release Hold and Notify Approver sends a held request on. See Answer Flags.
Forward / Re-send on an e-mail sends a copy to an address you enter.
Delete on an e-mail removes it from the correspondence list. Only architects see it.
Re-generate and Send E-mails appears when a request on a view with stages has no e-mails at all. It sends the requester's confirmation and the first approver's e-mail, for a submission that was saved but whose e-mails failed.

Choosing the right fix

The approver says they never got the e-mail. Check E-mail Correspondence. If it is there, Forward / Re-send it to the right address. If the list is empty, use Re-generate and Send E-mails.
The requester answered outside the form. Use Close Information Request rather than Rollback, which would lose the record that information was asked for.
A stage was approved by mistake. Use Rollback to Previous Stage and choose enough days for the approver to act again.
A field was entered wrongly. Use Edit Details.

Worked example

A supervisor rings to say they deleted the approval e-mail for application WX-2231. The co-ordinator opens Expiring Soon, sees the request has five days left, and presses Open. Under E-mail Correspondence they find the supervisor's e-mail and use Forward / Re-send to send it again. Two weeks later the student phones in the answer to a question the supervisor asked; they press Close Information Request, type the answer, and the supervisor receives a fresh link.

Recommendations

Read the correspondence first before changing anything.
Prefer Close Information Request to a rollback.
Give rollbacks enough days so the time-out does not undo your fix.
Use Action Request sparingly; it is recorded as the stage's own decision.

Expiring Soon: Time-outs Before They Happen

Expiring Soon lists every request that a stage time-out will act on within the next few days, so somebody can chase the approver or the requester before the request is declined or moved automatically. It is the same rule the time-out task uses, asked earlier, so it never disagrees with what will actually happen.

Where to find it

Admin Panel → Processes:

Expiring Soon — requests about to time out, with Open and Pause

Architect Panel → Configuration:

Site Settings — Days ahead to warn about time-outs, in the Stage Time-outs group

The tile is visible to nobody until you grant it to a security group, because it lists named applicants. See Admin Panel.

Reading the screen

A banner at the top says what the time-out task is doing:

No scheduled task for stage time-outs: nothing listed will ever time out.
Switched off: nothing will time out until the task is enabled.
Live: everything listed will be actioned automatically when it falls due.

Below it, Showing requests timing out within 7, 14, 30, 60 or 90 days; the default comes from the Site Settings value (14 unless changed). Each request shows:

Ref and Form.
Waiting At: the stage.
Waiting For: Approver, or Applicant (more information) when the requester has been asked something.
Waiting Since, Times Out and Days Left, with due today in red.
Actions: Open goes to the request's progress page; Pause stops the clock.

You only see requests on forms whose datastore you can read, and Pause only appears where you hold Edit Existing.

Pausing a time-out

Press Pause on the request.
Enter the number of days, between 1 and 365 (14 is suggested).
The request drops off the list. It is not declined, moved or changed: it simply is not counted until the date passes, by the time-out or by approver reminders. It then reappears if it is still waiting.

What is and is not listed

Listed: requests on stages with a time-out set, falling due within the window.
Not listed: anything already overdue. It has timed out, or will at the next task run, and shows under Timed Out Requests once it has.
Not listed: requests whose stage is still holding back a delayed approver e-mail, and requests already paused.
Not listed: requests on stages with no time-out. Nothing will act on them.

Using it as a routine

Grant the tile to the group that runs the process.
Set Days ahead to warn about time-outs to suit your stages: a little longer than your shortest time-out is a good start.
Check the screen daily or weekly. Chase approvers by phone or by re-sending their e-mail from the progress page.
Pause only for a known reason, such as a supervisor on leave, and for no longer than needed.

Worked example

A co-ordinator runs 300 applications with a ten-day supervisor time-out. They set the warning window to 14 days and are granted Expiring Soon, which also adds a Timing Out Soon tab to their applications list. On Monday the screen shows six requests, two of them Applicant (more information). They chase the four supervisors and e-mail the two students. One supervisor is away for a fortnight, so they pause that request for 14 days rather than let it time out.

Recommendations

Check the banner first. A list beside a switched-off task is a forecast that will not come true.
Use it as the dry run before switching the time-out task on.
Pause sparingly, with a reason you could explain later.
Grant it narrowly. It shows named applicants.

The Process Inspector

The Process Inspector shows, in plain words, how every approval process on the system is configured: where requests start, who is e-mailed at each stage, which fields each approver sees, what they can do, and what happens if nobody acts. It changes nothing, so it is safe to give to people who need to understand a process but should not edit it.

Where to find it

Architect Panel → Forms:

Process Inspector — every architect sees it, with edit pencils beside each setting

Admin Panel → Processes:

Process Inspector — read-only, once granted to a security group

The Admin Panel tile ships visible to nobody. Whoever opens either tile sees only processes whose datastore they hold Read on.

The list

The first screen lists every process you can read, with its datastore, the number of stages (counting the form itself as stage 1) and the reference prefix. Open one to see its detail.

Inside a process

The heading: datastore, number of stages, reference prefix, and whether declined requesters may re-apply.
A task warning, if any time-out, reminder or delayed e-mail on the process depends on a scheduled task that is not installed, switched off, or enabled in a way that will not run. Each line names the task and the stages affected.
Process settings: Where a request starts (Initial Stage Assignment), Where it ends (the Process Complete Action) and Custom code (a first-stage callback, if any).
E-mails sent by this process: who the requester is, and each requester e-mail (confirmation, approved/progress, completion, declined, cancellation, request for more information) with its template.
Flags raised by the answers: the flag rules, if the view has any.
Application windows: whether the intake bindings are complete, how many rounds are open today, and anything that would refuse applications. See Application Windows & Shortlisting.
Stages, in the order a request travels, with a rail to jump between them. Each stage has:
- On arrival: what happens when the request reaches it.
- The approver: what they can do, and the extra questions each button asks (Also asked for), which are stored against the decision rather than on the record.
- Timing: If nobody acts in time, Reminder e-mails, and Reminders while waiting for more information.
- Fields shown at this stage: which fields the approver reads and which they can change.

Amber means switched on but empty

A setting set to Yes with nothing filled in, such as a time-out with no period, is shown in amber rather than as a plain Yes. Every task that reads those settings skips them, so they look on in the builder and do nothing. Fix them in the builder.

Using it to answer questions

"Why did this go to Jane?" Read Where a request starts, then On arrival for that stage.
"Why has it sat there a fortnight?" Read Timing for the stage, then the task warning at the top.
"Where did the decline reason go?" Read Also asked for: it is stored with the decision and shown on the request's progress page, not on the record.
"Why is the form refusing applications?" Read Application windows.

For architects

Opened from the Architect Panel, the screen shows a pencil beside each setting. Most open the row editor for the view or stage; the pencils beside The approver and Fields shown at this stage open Form Stage Actions and the visibility override. Stage 1 has no row of its own, so it has no pencil.

Worked example

A hospital's HR team asks why reminders stopped on its Study Leave process. An architect grants the Admin Panel tile to the HR managers' group, and the HR lead opens the process. The task warning reads that the reminder task is switched off for stages 2 and 3, and stage 3's If nobody acts in time is amber. The architect enables the task, fills in stage 3's time-out, and the HR lead re-opens the inspector to see both warnings gone.

Recommendations

Grant it to process owners; it is read-only.
Check it after every change to a process.
Treat amber as a fault to fix, not a style.
Start with the task warning when something timed is not happening.

The Approver Request List

Approvers on a user input view usually have no account: the e-mail carrying their decision link is the only copy. The approver request list gives that link back. An approver proves they control their mailbox and sees every approval link already e-mailed to that address, without being given an account.

Where to find it

Architect Panel → Configuration:

Site Settings — the Approver Request List group switches it on and sets its rules

The page approvers use is at /ajax/uivrequests.php on your site. It ships switched off; until you enable it the page says This page is not available.

How it works for an approver

They open the page, enter Your e-mail address and press E-mail me a link. The page answers the same way whatever address is entered, so it cannot be used to discover who your approvers are.
If the address is allowed, they receive an access link. It works for a set number of minutes and can be used repeatedly within that time, so the browser Back button does not break it.
The link opens Your approval requests: one entry per request, those still awaiting their decision first and then the most recently e-mailed, with its process, stage, reference number, when it was first sent and how many reminders followed.
Each entry has a status such as Awaiting your decision, You approved this, You declined this, You asked for more information, Timed out, Cancelled by the applicant or Declined at another stage, and a link to open it.

The page can only re-show links that were actually sent to that address and are still valid. It never creates a link, never reaches a request that address was not sent, and never signs anybody in.

The settings

Enable the approver request list: the master switch, off by default.
Accepted e-mail domains: semicolon-separated. Leave empty to accept any domain. A leading * matches sub-domains only: *.nhs.uk accepts trust.nhs.uk but not a bare nhs.uk address, and not nhs.net. List each form you mean, for example *.nhs.uk;nhs.uk;nhs.net.
Minutes an access link lasts: default 60, between 5 and 1440.
Send access links from: the e-mail account ID that sends the access link. At 0 it works only when there is exactly one account; with several and none named, nothing is sent. Set it explicitly.
E-mail log rows to examine: how far back through sent mail one page load looks, default 5000. When the limit is reached the page says older requests may not be listed.

Telling approvers it exists

Once it is switched on, automatically written approver e-mails include a sentence linking to the page. A stage that uses its own e-mail template gets that sentence only if the template contains ##AMDATA/MYREQUESTSLINE## (the sentence) or ##AMDATA/MYREQUESTSURL## (just the address). While the feature is off both tags are replaced with nothing, so they are safe to add in advance.

Before you switch it on

It is a disclosure decision. Anyone who controls an approver's mailbox can already read the links in it; this makes them reachable from a web page too, for as long as the access link lasts. Agree it with whoever owns the process.
Check your approvers' domains. A domain rule that leaves some out fails silently: those approvers see the same check your e-mail message and simply never receive anything.

Worked example

A work-experience hub's placement supervisors keep deleting approval e-mails and then asking for applications to be re-sent. The hub enables the list, sets Accepted e-mail domains to *.nhs.uk;nhs.uk;nhs.net after checking that none of its supervisors use another domain, names the hub's own e-mail account in Send access links from, and leaves the link lifetime at 60 minutes. Supervisors now find the page linked in every automatically written approval e-mail and recover lost links themselves.

Recommendations

Agree the disclosure before enabling it.
List every domain form you need; the wildcard does not cover the bare domain.
Name the sending account.
Add the tag to custom approver templates so the page is discoverable.