A module can carry scheduled reminders tied to its entries — things like “notify the assignee on the due date” or “remind the team 3 days before the deadline”. Behind the scenes, every time anyone saves an entry, Inistate re-checks that entry’s reminders and adjusts the schedule.
One detail matters more than it sounds: performing any activity on an entry counts as saving it. Approving it, adding a status update, editing an unrelated field — each of these re-saves the entry and re-runs the reminder check.
This post sets out exactly what happens to a reminder in each situation.
The four promises
- One reminder per rule, per entry. Saving an entry — no matter how many times, no matter which activity — never creates a duplicate of an existing reminder.
- Sent means sent. Once a reminder has gone out, later saves of the entry will not send it again for the same date.
- The reminder follows the date. If the date it is tied to moves, the reminder moves with it — one reminder, rescheduled, not a second one added.
- A missed moment is cancelled, not fired late. If a reminder’s moment is already in the past (because a date was moved backwards), it is quietly cancelled. You never get a reminder for a day that has already gone by.
How a reminder gets scheduled in the first place
- Relative timers — “2 days after this happens” sets a reminder two days out. Minute- and hour-based timers get an exact time of day; day-based ones are scheduled for the day itself.
- Date-field reminders — a reminder tied to a date on the entry (like a due date) fires on that date, at a specific time if one is configured.
- Lead-time reminders — “3 days before the due date” is calculated from the entry’s current due date, and recalculated whenever that date changes.
What editing an entry does to its reminders
| Someone does this | What happens | Outcome |
|---|---|---|
| Saves the entry without changing anything, or performs an unrelated activity | The existing reminder stays on its date — nothing is duplicated, nothing is re-sent | Kept as is |
| Updates the entry after today’s reminder already went out | The reminder was delivered for this date, so it is not sent again | Sent stays sent |
| Pushes the due date later | The same reminder moves to the new date — never a second one | Rescheduled |
| Pulls the due date earlier, still in the future | The reminder moves earlier and fires on the sooner day | Rescheduled |
| Moves the due date to today | The reminder is rescheduled onto today and goes out today | Fires today |
| Moves the due date into the past | The waiting reminder is cancelled — it never fires for a day that has gone by, and does not stay armed on its old date | Cancelled |
| Moves a date so a “days before” reminder lands in the past | The lead-time moment has passed, so the reminder is quietly dropped — no late ping | Cancelled |
| Changes the due date to a new day after the reminder was sent | A new date is a new occasion — a fresh reminder is scheduled for the new day | New reminder |
| Pushes the date out after delivery, then pulls it back to the already-reminded day | Nothing re-sends, and the reminder left waiting on the abandoned date is cancelled so it cannot fire days later | Cleaned up |
| Edits an old entry days after its reminder went out | A finished reminder is never resurrected by a later save | Stays quiet |
What never touches reminders
- Editing the module’s design. Changing the form or workflow layout does not re-run any entry’s reminder check. Only saving an entry does.
- Modules with only “run immediately” automations. If a module has no scheduled rules at all, saving its entries skips the reminder machinery entirely.
- Other scheduled automations on the entry. When an entry changes, its waiting scheduled automations (the non-reminder kind) are flagged to recalculate so they run against fresh data — but ones that already ran are left finished, exactly like delivered reminders.