An approval reminder should normally point the reviewer back to the existing request, not create a second approval simply to send another message. Keep the request identifier and business state available so a scheduled reminder can decide whether the original decision is still outstanding.
Begin with a clear process rule: when a reminder is due, who receives it and when reminders stop. This guide presents a design and validation approach, not a deployed flow template. Confirm the supported connectors, permissions and licensing for the actual implementation.
Separate a notification from an approval action
Microsoft's approvals introduction describes approval requests and ways users can respond. Creating another approval is a new business object, not merely another delivery of the first message. Two request IDs can produce conflicting responses even when their titles are identical.
Write down which action creates the original request and which action sends a reminder. The reminder path should have an explicit reason to reuse the existing request context. If the design intentionally replaces an approval, label that as replacement and handle the earlier request separately.
Store the request identity
Keep the approval identifier alongside the source item and revision marker in an approved process record. Do not use the email subject as the only identity. A subject can be reused, edited or truncated without distinguishing separate requests.
Store the business deadline
A desired review date is different from the technical lifetime of a flow run. Record the deadline and its time-zone convention. A reminder should not interpret an action timeout as a human rejection or a completed review.
Define the reminder's eligibility checks
Before notifying, recheck that the request remains valid and outstanding, the reviewer is still assigned and the source revision remains appropriate. If the record is already completed or withdrawn, the reminder should not invite another response as if nothing changed.
| Condition | Reminder decision to define |
|---|---|
| Still pending and due | Send the approved notification for the existing request |
| Completed or withdrawn | Do not send a pending-review reminder |
| Reviewer changed | Use the current authorized assignment and process rule |
| Source revision changed | Apply the organization's resubmission or cancellation decision |
Design for retries and overlapping runs
A schedule can execute while another reminder is still being processed. Record an appropriate notification state and consider the supported mechanism for preventing duplicate sends. An ordinary read followed by a write is not automatically an atomic claim.
Define what happens if the message sends but the record update fails. Retrying blindly can send the reminder twice. Keep a correlation between the request, intended reminder occurrence and operational result so recovery can inspect what already happened.
Avoid holding the whole process open indefinitely
Microsoft's flow limits describe runtime and other constraints relevant to designs that wait for long periods. Choose a supported architecture for reminders and response handling rather than assuming one waiting run can cover every business deadline.
A separate scheduled review of persisted pending requests may be appropriate for a particular design, but it still needs access controls, ownership and a clear stop rule. Do not treat a recurrence trigger as a complete approval-state database.
Make the message specific and restrained
Include the purpose, original request context, due date and supported route to the existing approval. Avoid unnecessarily reproducing confidential document contents in a notification. Confirm that the reviewer can open any linked source under their normal account.
Set a reasonable notification cadence with the process owner. Repeated messages every few minutes can obscure genuinely important exceptions and frustrate reviewers. Escalation to another person is a different action from a reminder to the same assignee and should have its own rule.
Test completion around the reminder time
Use a pilot case where the reviewer responds just before a reminder is evaluated, another where the request is withdrawn and another where sending fails. Check both the number of approval IDs and the actual messages. A successful flow run alone does not establish that the notification was appropriate.
These are proposed acceptance tests, not claims that a particular design has eliminated duplicates. Record the observed cases and any recovery limitations before using real business requests.
Our SharePoint approval workflow guide provides the wider request-state context. A useful reminder design preserves one clear decision request, checks whether it still needs attention and makes retries understandable. Creating another approval should be an intentional process change, not an accidental consequence of trying to send a follow-up message.
For requests approaching or exceeding a waiting run, review approval timeouts and outstanding request state.
