ActiveManage Docs ← Back to activemanage.co.uk

Stage Information Request Reminders

The opposite direction from a standard stage reminder: when an authoriser picks the "Request More Information" action, the request reverses back to the requester. They're now the one holding the workflow up, and the platform can chase them in the same way it chases authorisers.

This article covers the initial more-info email plus the per-stage reminder behaviour that nudges the requester if they don't reply quickly. Both pieces are configured on the UIV and inherit the same reminder settings used for forward-direction nudges, but it's worth understanding the directional difference because it changes who you're writing the email to.

The initial "more info needed" email

The first message in the reverse direction is the Request More Information email, configured on the parent UIV itself (not on the stage). Open the UIV's main configuration and find the Request More Information E-mail setting; pick the template you want to use.

The template can use the standard set of merge tokens — reference number, requester's name, request URL — plus any field from the original submission via ##AMDATA_fieldname##. A well-written more-info email includes:

  • A clear statement that more info is needed (in the subject line as well as the body, so the requester sees it before opening).
  • What was already submitted, summarised — saves the requester from having to look it up.
  • The specific question or clarification the authoriser asked. The platform's stage configuration includes a free-text notes field that authorisers fill in when sending back; that text appears in the email.
  • A direct link back to the request (##REQUESTURL##) so they can edit and resubmit with one click.

If you leave the template blank, ActiveManage auto-composes a polite message asking the requester to revisit the form. That's a fine fallback but rarely as targeted as a custom template.

What the requester sees when they click through

The link in the email leads back to the original submission form, pre-populated with everything they originally submitted. A notes area shows the authoriser's question. The requester edits whatever's needed (or just clarifies in the notes area without changing anything else) and resubmits.

After they resubmit, the request returns to the same stage where the authoriser left off — not back to the beginning. The authoriser sees the resubmission in their queue with the updated values highlighted (where the data changed) and the new note from the requester.

Reminding the requester

Because the workflow is paused waiting on the requester, the system can also send them reminders if they don't act. These follow the same reminder pattern as the main Stage Email Reminders — they're per-stage, support seconds through to years as the unit, and use a chosen template.

Note: The same reminder configuration on a stage works in both directions. If the stage is waiting on the authoriser, the reminder is sent to the authoriser. If the stage is waiting on the requester after a more-info request, the reminder is sent to the requester instead. You don't need to configure them separately, but you might want to use different templates depending on who's being chased — the platform supports a separate reminder template specifically for the requester-direction case.

Best practice patterns

Three concrete suggestions for designing your more-info flow:

Keep the initial more-info email warm and specific

Reference what was submitted (using ##AMDATA_fieldname## tokens) so the requester knows exactly what part of their submission needs revisiting. Generic "please provide more information" emails are confusing — the requester opens them and isn't sure what's wrong.

Use shorter reminder intervals for requester-direction nudges

Requesters are more likely to have forgotten about a submission than authorisers are — they hit submit and moved on. A 24-hour reminder window is reasonable when chasing the requester; a 3-day window is reasonable when chasing the authoriser.

Build in a self-cancellation timeout

If a request genuinely gets stuck waiting on a requester who's gone quiet, use the Stage Timeout feature to auto-cancel after a longer threshold (e.g. 14 days). That way the request doesn't sit forever in the open queue — it's politely closed with a final email and an option to re-submit later.

Three real-world examples

Different UIVs benefit from different more-info flows:

  • Customer Support Ticket: Initial more-info email is friendly ("We need one more detail to help you. Can you tell us…?"). Reminders fire every 24 hours up to 3 reminders, then the stage auto-cancels with a polite "we'll close this for now — please re-submit if you still need help".
  • Internal Procurement Request: Initial more-info email is structured ("Finance has asked for: a) supplier tax ID; b) cost breakdown by line item"). Reminder fires once after 2 days. No auto-cancel — finance will chase by phone if the request goes stale.
  • External Vendor Onboarding: Initial more-info email is formal ("Your application is in review pending additional information. Please log in and complete the following sections by the deadline below."). Reminders fire after 3, 7, and 14 days. Auto-cancel after 30 days with a re-application option.

Diagram showing the more-info request flow: stage authoriser picks Request More Information, requester gets an email with the question, requester clicks through to a pre-filled form, resubmission returns to the same stage