Delayed Stage E-mails

A stage can hold back the e-mail it sends its approver until a date on the form is reached, or until a set time after the request arrives. Use it when the approver should not be asked yet: a feedback request that only makes sense once a placement has finished, or a sign-off that waits for a start date.

Where to find it

Architect Panel → Forms:

User Input Views — Manage Stages, then Delay E-mail inside the stage's Send E-mail action
Process Inspector — the stage's On arrival panel

Architect Panel → Automation:

Tasks — User Input View - Delayed Stage E-mails, which must be enabled

The choices

Delay E-mail sits inside the Send E-mail stage action. Its options are:

No - send immediately: the normal behaviour, and what every stage saved before this option existed does.
Yes - when a date field is reached: enter the Date Field Row Name of a date field on the form. The e-mail goes out on or after midnight at the start of that date, server time.
Yes - a set number of minutes, hours, days, weeks, months or years after reaching this stage: one option per unit, each with a number to enter.

How it behaves

The request still arrives at the stage straight away. Only the approver e-mail waits. The requester's own progress e-mail is not delayed.
Every route into the stage is covered: approval from the previous stage, a new submission routed straight to it, and a transfer or time-out that moves a request there.
It is sent once. A failed send is tried again on the next run rather than being lost.
Reminders and time-outs wait for it. No reminder goes out, and the stage does not time out, until the delayed e-mail has actually been sent. A request is not declined before its approver has been told. Their clocks still run from when the request reached the stage, though, not from the e-mail.
A date that is empty or unreadable means the e-mail cannot be scheduled yet. It is checked again on each run and goes out once the field holds a date that has been reached.

Setting it up

Make sure the date field you want to use is drawn on a stage at or before this one, so it is filled in by the time it matters.
Open the stage from Manage Stages. Its Stage Action must be Send E-mail.
Set Delay E-mail and fill in the date field's row name, or the number of units.
Save, and read the stage's On arrival panel in the Process Inspector to confirm the delay.
Enable User Input View - Delayed Stage E-mails on the Tasks screen.

What goes wrong

The task is switched off. This is the serious one: the stage suppresses its e-mail and nothing ever sends it, so approvers are never asked. Enable the task before you save a delay on a live stage.
The row name is the field's title rather than its row name. The value is never found and the e-mail never sends.
A date field the requester can leave blank. Make it required, or the approver may never be asked.
A delay longer than the time-out. The moment the delayed e-mail goes out, the request is already overdue, and the next time-out run declines or moves it. Make the time-out longer than the delay.
Two runs at once, possible only when a previous run overran, can in rare cases send twice.

Worked example

A placement programme asks each supervisor for an evaluation of the student at stage 5. The request reaches that stage when the co-ordinator confirms the placement, often weeks before it starts. The architect sets stage 5's Delay E-mail to when a date field is reached with the row name of the placement end date. The supervisor is e-mailed the morning the placement ends. Because reminders and time-outs count from when the request reached the stage, not from the e-mail, the architect sets the stage's time-out longer than the longest placement plus the time a supervisor needs, so a request is never timed out the day its e-mail goes.

Recommendations

Enable the task first, then add delays.
Use a required date field for date-based delays.
Use a fixed period when there is no natural date.
Check the On arrival panel in the Process Inspector after saving.