Send a reminder when something is overdue sounds like a small scheduled flow.
The hard part is the word overdue.
Before you build the recurrence, turn it into a business rule.
For example:
Every weekday morning, find items where Status is still open and DueDate is before today, then remind the current owner.
That sentence already defines more of the flow than a screen full of actions.
Define the boundary
Decide:
- does due today count as overdue?
- does the comparison use date only or date and time?
- which business time zone defines today?
- what happens when DueDate is blank?
- what happens when Owner is blank?
- which statuses count as open?
A useful simple rule might be:
- DueDate yesterday + Open → remind;
- DueDate today + Open → do not remind;
- DueDate yesterday + Complete → do not remind;
- blank due date → visible exception;
- blank owner → visible exception.
Whatever rule you choose, write it down before translating it into the filter.
Retrieve the right items first
A common scheduled pattern is:
- Recurrence trigger.
- Retrieve open items whose due date is before the overdue boundary.
- Work through the returned items.
- Send a concise reminder to the responsible owner.
- Optionally record the last reminder date or reminder count.
Filtering at retrieval is usually better than pulling every item and deciding later.
Keep the business rule aligned with the filter expression.
Make the message useful
A reminder should contain enough information to act.
Typical fields are:
- reference;
- action or request;
- due date;
- owner;
- current status;
- direct link where appropriate.
Avoid vague messages such as Something is overdue.
The recipient should not need to search several systems to find the work.
Handle blank data deliberately
Do not let a missing owner produce an empty or misdirected email.
Do not let a blank due date become overdue because an expression happens to interpret it oddly.
Create a visible exception path.
For example:
- blank owner → Needs Assignment;
- blank due date → Needs Review;
- invalid status → configuration/data exception.
An exception queue is better than silent disappearance.
Decide whether reminders may repeat
A daily reminder may intentionally repeat.
An escalation usually should not.
If the business rule is remind every weekday until complete, then a new message each day is expected.
If the business rule is send one reminder after 3 days, then one escalation after 7 days, the flow needs durable state such as:
- ReminderSentDate;
- EscalationLevel;
- EscalationDate.
Do not infer escalation history from old email messages if the tracker can store it directly.
Escalation is process state
For escalation, calculate the applicable threshold and compare it with the level already recorded on the item.
Only send the next notification when the candidate level is greater than the stored level.
After a successful notification, update the tracker immediately with the new escalation level and date.
That prevents the same threshold from generating the same escalation every day.
Be explicit about local time
A schedule that says 08:00 is incomplete without a time-zone rule.
Date boundaries are particularly easy to get wrong when a system stores date-time values in UTC while the business interprets today in local time.
Use the business time zone deliberately and test records around midnight or another relevant boundary.
Test more than one date
Create controlled items such as:
- due yesterday and Open;
- due today and Open;
- due tomorrow and Open;
- due yesterday and Complete;
- blank owner;
- blank due date;
- already reminded at the current level;
- due long enough to reach the next escalation threshold.
Then confirm both:
- which records were returned;
- which messages were actually sent.
Common failure modes
Every open item is reminded
The due-date boundary or retrieval filter is wrong.
Due-today items receive messages
The business definition of overdue and the implemented comparison do not match.
The same escalation is sent every day
The tracker does not store durable escalation state, or the flow does not compare the candidate level with the current one.
The wrong person receives the message
The owner value or mapping is not authoritative.
The schedule fires at the wrong business time
The recurrence or date expression is using a different time zone than the process expects.
Keep the policy outside the flow where it changes often
A simple threshold can live directly in the flow.
If reminder and escalation rules vary by request type or change frequently, a maintained configuration list can be easier to audit than a large set of nested conditions.
The goal is not maximum cleverness.
The goal is a reminder process whose decisions are visible, repeatable, and explainable.
If the scheduled flow fails or sends the wrong set of messages, use the run-history diagnosis guide before changing several actions at once.