Approval workflow reminders: pending, late and changed requests

Write the decision rules before adding reminders

An approval workflow needs to answer four questions: what is being approved, who can decide, how long the decision stays valid and what happens next. A reminder helps only after those rules are clear.

Start with an ordinary internal request, such as checking a project handover document. Keep the approved document version, the decision and the resulting work together. A reply that says “looks good” is hard to use safely if nobody can tell which version it refers to.

• Pending: a named reviewer still needs to decide.
• Approved: the required person or people accepted the exact version.
• Rejected: the request needs a recorded correction or ends.
• Expired: the decision window ended without a valid approval.
• Superseded: a newer request version replaced the old one.

These are suggested states for your request record. They are not a promise that every platform uses these exact labels. Keep the platform's approval result as well as your business state, because the two can become different when a flow times out or a document changes.

Keep enough information to explain each decision

Use a request list or database with a stable request ID. Store the approved snapshot in a location the reviewer can actually open. A link alone is not a snapshot if the document behind it can change without tracking a version.

Store times as instants with a clear time zone. Display the reviewer's local time where useful. If a policy says “two business days,” define the business calendar separately. Adding 48 hours does not skip weekends or holidays.

Build a small Power Automate approval flow

For a first test, use a dedicated SharePoint request list and one internal reviewer. Confirm the needed connections and environment are already allowed. Approval features can require environment setup and the right user access. Check Microsoft's prerequisites.

1. Start when a new test request is created. Validate the reviewer, document reference, version and due time before creating an approval.
2. Record the request as pending. Use Create an approval, save its returned ID, then use Wait for an approval for that ID. These are separate actions; creation alone does not supply a completed decision. Compare the approval actions.
3. After a successful wait, inspect the actual approval response. Continue only when the required approval rule is satisfied and the current request is still the same pending version.
4. Write rejected, expired, changed and failed cases to a review queue. Configure failure and timeout handling; a success-only path leaves these cases invisible.
5. For this small exercise, the approved action creates one internal handover task. Save that task's ID so a later retry can find it.

Microsoft's approval walkthrough is the starting point for the platform configuration. The version check, reminder schedule and recovery record here are additional application design work. They are not added automatically by choosing an approval action.

Before connecting a real action, test by writing a result to the test list. Only use test recipients and invented document content during the exercise.

Keep Create and Wait close together, with only the needed ID save between them. Microsoft documents a possible issue when someone responds before the wait starts. Test an immediate response and avoid adding slow work between the actions. Check this known issue.

Example 1: One reviewer approves the current version

Input: REQ-730 version 2 asks a project owner to review a handover checklist. The record is pending. The reviewer opens the versioned document and approves it before the due time.

Set it up: Capture the response with its approval ID. Re-read the request and confirm the reviewer, version and pending state. Then claim the action for that request before creating the handover task.

{"request_id":"REQ-730","version":2,"business_state":"approved","decision":"Approve","applied_action_id":"TASK-184"}

Expected result: One internal task and a saved decision trail. The task ID proves which work was created. It does not mean the handover itself is finished.

Failure check: Make the task destination unavailable after approval. The record should show an approved request with a failed action, not a rejected request. Keep those separate so the owner can retry the write without asking for the same decision again.

These sample field names belong to the proposed tracking record, not a ready-made Power Automate response payload.

Example 2: Rejection records a reason and stops the action

Input: The reviewer rejects version 2 because the checklist has no support contact.

Set it up: Store the rejection and comments. Route the item back to its requester. Do not treat every response other than a timeout as approval. Inspect the exact decision value returned by the selected action.

Expected result: No handover task is created. The request remains visible as rejected, with a clear correction. If the requester adds the contact, create version 3 and begin a new review rather than rewriting the rejected version's history.

Failure check: Submit an empty or unfamiliar decision in a local test fixture. The safe result is a manual review item. It should not fall through to the approved branch.

A request can need more information without being a permanent refusal. Decide whether that uses a separate business state or a rejection reason, then explain the rule to requesters and reviewers.

Example 3: A pending request receives one reminder

Input: REQ-731 is due October 2 at 17:00 UTC. Your example policy sends one reminder on October 1 at 17:00 UTC, then escalates to the process owner at expiry. These times are a test policy, not a recommended deadline for every business.

Set it up: Create a separate scheduled flow using Recurrence. It reads pending requests whose next reminder time has arrived. Before sending, re-check the current state and version. Record a reminder key such as REQ-731:2:reminder-1 and the send result. See scheduled cloud flows.

Expected result: One reminder links to the existing approval. It does not create a second approval request. The next schedule run recognizes the recorded reminder and does not send it again.

Failure check: Approve the request while the reminder flow is running. A final state check narrows the race, but separate systems cannot guarantee the email and decision happen as one transaction. Phrase the reminder as “If this is still pending” and make its link show the current status.

For strict repeat prevention, use a unique reminder key and a coordinated writer. If email delivery times out, investigate the uncertain send before resending. A sent flag written after an email is not a guarantee that duplicates are impossible.

Example 4: Expiry stops the business action

Input: The due time passes with no valid decision. The scheduled check changes the business state to expired and tells the process owner it needs attention.

Set it up: Make the action path reject a late response to an expired request. Do not confuse ending your flow with removing an approval from the platform's action center. Track the outstanding approval ID so the requester can close or cancel it using the supported process.

Microsoft documents a 30-day maximum cloud-flow run duration. Its approvals known-issues page separately describes a 28-day approval wait and possible abandoned approvals. Keep ordinary deadlines well inside those limits. For longer processes, follow the documented separate-flow and persisted-record approach instead of holding one run open indefinitely. Read flow limits, approval wait issues and long-running approval guidance.

Expected result: No handover task. The owner sees an expired item with its approval ID and next action.

Failure check: Respond to the old request after expiry. The late reply must not reopen the business action. If the work is still needed, issue a new review with a new valid deadline.

Example 5: A changed request or repeated response cannot create extra work

Input: Version 2 is awaiting approval when the requester uploads version 3. A delayed approval for version 2 then arrives twice.

Set it up: Mark version 2 superseded. Keep its snapshot and approval ID for history. The action writer accepts only the current, approved version and uses a unique action key such as REQ-730:3:handover.

Expected result: Both old responses are recorded or ignored as stale. Neither creates a task for version 3. A new approval is required for the changed content.

Failure check: Run two identical approved events together. Both can pass a simple read-before-write check. Use a store with conditional updates and enforced uniqueness, or one coordinated writer that prevents overlapping claims. Test the store's actual behavior; a column called unique key is not enough unless uniqueness is enforced.

Also test a crash after the task was created but before its ID was saved. Keep a stable reference in the destination or route the uncertain result to an owner who can recover it. Blind retries can create a second task even when the approval itself was processed only once.

Example 6: Two named reviewers need the right rule

Input: The delivery lead and support lead must both approve the handover. Either can reject it. The first reply is an approval from the delivery lead.

Set it up: Choose the approval type that requires everyone to approve. Microsoft's first-to-respond option completes when one assigned person approves or rejects; that would not meet this requirement. If the support lead must review only after delivery finishes, use a sequential process instead. Compare the approval types.

Expected result: The first approval leaves the request waiting for the other required decision. A later rejection stops the approved action. Record whose response is still missing.

Failure check: Remove one reviewer from the available test accounts. The request should need an owner decision about reassignment. Do not silently change “both must approve” into “whoever is available.”

Keep a backup process for absences. Record who is allowed to reassign an approval and whether the replacement reviewer must see earlier comments. A timer should not choose a substitute authority on its own.

If your team uses Zapier, Make or n8n

Keep the same decision rules even when the platform changes. Zapier Human in the Loop offers a reminder and timeout behavior. For a gated action, choose Stop run on decline and End run on timeout, and check the approved decision before continuing. Its reviewer access rules and placement limits still apply. Check the current settings.

For Make or n8n, first decide where the authorized reviewer will make the decision and where its versioned record will live. A public webhook URL with an approval flag is not enough to prove who decided. Use an authenticated review surface and validate the request version before the writer acts.

You may already have a suitable approval feature in your project or document app. Use that when it handles the required people, history and states. Add an integration only for the handoff it does not cover.

Test the decision and the resulting work separately

Run all six examples with invented requests. Record the input, expected state, actual state, decision ID, reminder count and destination task count. Include an unavailable reviewer, a changed document, an overdue decision and an uncertain write.

Check three things after each run: the reviewer saw the correct version, the request shows the correct state, and the destination contains only the authorized work. Review both a successful run and an exception before you enable the workflow for a real team.

Give the owner the pending queue, the expired queue and the failed-action queue. Those lists answer different questions. Measure time waiting for a decision separately from time spent repairing automation.

For invoice documents, use the invoice intake and review guide. For app-side failures, use Power Automate error handling. For time-zone rules, use the date examples.

Sources

Primary documentation checked September 26, 2026. These are proposed workflows with synthetic cases, not results from connected account tests.

• Microsoft: approval types and prerequisites
• Microsoft: creating and managing approvals
• Microsoft: approval action differences
• Microsoft: scheduled flows
• Microsoft: flow limits
• Microsoft: known approval issues
• Zapier: review actions, reminders and limits