build.allanninal.dev

Part 5 of 7 · Deadline reminder series ~5 min read

How a deadline gets marked done

A reminder lands in Dana’s Slack DM at 8:03am. The Q1 sales-tax filing is due in 14 days. There’s a Done button. What happens when she taps it? The honest answer is “it depends on what she actually did.” This post walks through the three things the system can do on a reminder — done, snooze, ack-only — and how the calendar, the chain state, and the audit trail all stay in sync.

Key takeaways

  • Three actions per reminder: done (roll the date forward, fresh chain), snooze (delay), ack-only (silence this cycle).
  • Each action updates the calendar sheet via the Sheets API and writes an audit row.
  • Marking done archives the old cycle’s chain to a separate sheet for history.
  • Snooze is bounded — you can only snooze a few times before the system escalates anyway.
  • The Done button is a Slack interactive message backed by a Function URL.

Three actions on Done

Three actions on the Done button A diagram showing one input on the left flowing through a small interactive Slack panel, then branching into three action paths. Far left: a "Reminder in Slack DM" box showing a typical reminder message — deadline name, type, days remaining, link to reference — with three Slack-button placeholders below: Done, Snooze, Ack only. The owner taps one button. The middle column shows the three branches. Branch one, Done: optionally opens a Slack modal confirming the date this cycle was handled. On confirm, a Function URL Lambda rolls the next due date forward by the repeat interval, updates the calendar sheet via the Sheets API with the new next-due date, archives the old cycle's chain history to a separate sheet, clears the chain state in the dr-reminders DynamoDB table, and writes a done event to the audit trail. Branch two, Snooze: opens a smaller Slack modal asking how many days to snooze (default 3); on save, the Function URL Lambda writes a snooze row to the dr-done table that suppresses reminders for that deadline until the snooze ends. The chain and due date aren't changed. Snooze can only be applied a limited number of times per cycle (default three) before the next check ignores it and reminds anyway. Branch three, Ack only: silences the rest of this cycle's chain; the system won't remind again until the next cycle. Useful when the owner is handling it themselves and doesn't want further reminders, but the due date hasn't been met yet. The right side shows the convergence: every action writes a row to the dr-audit DynamoDB table with timestamp, deadline id, action, by-user, and notes. A note at the bottom: Ack-only doesn't roll the date — it just stops the noise. The system remembers and the next cycle starts on schedule. Reminder in Slack deadline, days, link [Done] [Snooze] [Ack only] Action 1 Done • Confirm cycle handled on today’s date • Roll next due forward • Old cycle archived Action 2 Snooze • Modal: snooze N days (default 3) • dr-done row suppresses reminders until it ends Action 3 Ack only • Silence rest of cycle for this due date • No date change — due date stays Audit trail DynamoDB dr-audit timestamp · deadline_id action · by-user notes Ack only doesn’t roll the date — it stops the noise. The next cycle starts on schedule.
Fig 5. Three actions per reminder, three different effects. Done rolls the due date forward and starts a fresh chain. Snooze delays without dismissing. Ack-only silences the cycle without rolling the date. Every action writes to the audit trail.

Action 1: done (the most common)

Dana pulled the numbers, submitted the filing through the state portal, and now needs to tell the system it’s handled. She taps Done. For most deadlines that’s a one-tap confirmation; for a few the system opens a small Slack modal with one field — Date handled (defaulting to today, which is right most of the time) — in case she’s clearing a cycle she actually finished yesterday.

The tap submits to a Function URL Lambda. Three things happen, in order. First, the system computes the next due date by adding the repeat interval to the current cycle’s due date (a monthly payroll rolls forward one month; a quarterly filing rolls forward three; a yearly license rolls forward a year), then the Sheets API updates the row in the calendar sheet with the new next_due and a note in the last_done column with today’s date and the user who acted. Second, the existing cycle’s rows in dr-reminders are copied to dr-reminders-archive with a cycle id, and the live chain is cleared. Third, a action: done row is written to dr-audit with the user, timestamp, old due date, and new due date.

Tomorrow’s check reads the calendar, sees the new due date is more than the first lead time out, and lands at clear. The owner won’t hear from the system about this deadline again until the new cycle’s first step crosses.

Action 2: snooze (the deferral)

Some cycles take time the chain doesn’t plan for. The accountant is waiting on one last figure. The signer is travelling. The portal is down for maintenance. Dana isn’t ready to mark it done, but she’s also handling it — she just needs the system to be quiet for a few days.

Snooze opens a small modal asking for the number of days, with a 3-day default and a max of 7. On save, a row is written to dr-done with (deadline_id, snooze_until). The next day’s check reads that row in the “this cycle already done?” step from Part 3 and treats the deadline as clear until the snooze ends. When the snooze ends, the system re-evaluates the chain from where it was — if the deadline is now in escalation territory, the next reminder is an escalation.

Snooze is bounded. The rules doc has a configurable max_snoozes_per_cycle setting (default three). After that many snoozes on the same cycle, further snooze attempts are rejected with a “You’ve hit the snooze cap on this deadline; please mark it done or escalate” reply, and the next check reminds normally regardless. This is a soft constraint that exists because the most dangerous failure mode is repeatedly snoozing a filing past its actual due date.

Action 3: ack-only (the “I’ve got it”)

Sometimes the owner can’t mark it done yet and doesn’t want to be reminded again either. Maybe the obligation is being handled entirely outside the system this cycle (the accountant is filing on their behalf). Maybe the deadline is being retired. Maybe the owner just wants to confirm they’ve seen it and will handle it manually.

Ack only writes a row to dr-done with (deadline_id, ack_until: due_date) — effectively, “don’t remind me about this cycle again until its due date passes.” The due date itself isn’t rolled forward. The chain is silenced for the rest of this cycle. If the cycle ends up actually getting handled via Lane 1 (somebody just edits the next-due date in the calendar sheet directly), the new date resets the chain naturally on the next check.

If the due date passes without the cycle being marked done, the system does one more thing: it writes the deadline to a separate missed sheet in the same Drive folder, with the date it lapsed and the last-known owner. The missed sheet is what the monthly summary in Part 6 reports on. A missed deadline that was ack-only’d gets a small note — “ack-only by Dana on 2026-04-15” — so the audit trail isn’t a mystery later.

Every action is logged, every action is reversible

The dr-audit table records every done, snooze, and ack-only with the user who took the action, the timestamp, and a snapshot of the row before and after. If a wrong roll-forward gets entered (a quarterly deadline marked done a cycle early, say), a team member can run an “undo last action” through a small admin command that reads the previous-state snapshot and restores the row. The undo is itself an audit row, so the trail of edits stays clean.

This kind of reversibility matters most for the obligations you’ll only think about a few times a year. The next time the annual report comes up, it’ll be Dana again or it’ll be the person who took her job after she moved on. Either way, the audit trail is the only memory the next person has.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go.

All posts