Multi-Step Follow-Up Sequence with State Tracking

About This Build

This is a demonstration build. It exists to show how I handle a specific class of problem: automation that has to stay correct across days, when the world keeps moving between steps.

The visible part of the system is a multi-day outbound sequence with email and SMS. That part is not interesting. Any tool can send a message on a timer. The interesting part is everything that happens when the timer fires and the situation is no longer what it was when the timer was set.

The Actual Problem

A sequence that runs over ten days is not one workflow execution. It is somewhere between five and thirty separate executions, hours or days apart, each of which wakes up with no memory of the others.

Between any two of those executions, the following can happen:

• The contact replies, and continuing to send is now actively bad
• Someone on the team updates or closes the record by hand
• The same person submits a second form and enters the sequence again
• A step fails partway through and the platform retries it
• A webhook is redelivered, because webhooks are redelivered
• The whole thing is paused and resumed, and every pending timer fires at once

Sequences built as a chain of timed sends handle none of these. They have no memory, so they cannot detect any of it. The failure mode is not a crash. It is a contact who replied on day two and kept receiving scheduled messages until day ten.

Solution Architecture

One record, one source of truth

Each contact in the sequence has exactly one state record:

• Current step number
• Timestamp of the last confirmed send
• Timestamp of the last inbound event of any kind
• A lock field, with a holder and an expiry
• Status: active, paused, completed, or held

Nothing about the sequence lives anywhere else. There are no implicit timers carrying meaning, because a timer cannot be inspected and cannot be reasoned about after the fact.

Every step reads before it acts

A scheduled step does not send. It does this:

1. Take the lock, or exit if someone else holds it
2. Read the state record
3. Compare the step it was scheduled for against the step the record is on
4. If they disagree, the world moved. Exit without sending
5. If they agree, check status. Paused, completed and held all exit
6. Send
7. Write the new step and send time
8. Release the lock

Step three is the whole design. A step scheduled for day four that wakes up to find the record already on step six knows something else advanced it, and does nothing. This is what makes a resume-after-pause safe: every queued timer fires, and all but one of them exit at step three.

Idempotency on contact plus step

Every send carries an idempotency key of contact id plus step number. The send is recorded before the step advances. If a step is retried after the send succeeded but before the write completed, the retry finds the existing record for that key and treats the send as already done.

This is the difference between a retry being safe and a retry being a second message to a real person.

Replies write to the same record

An inbound reply, an SMS response, a manual note and a status change from the CRM all write to the same state record and set status to paused. They do not try to cancel scheduled work, because cancelling scheduled work reliably is harder than it looks and fails silently when it fails.

Instead, the next scheduled step reads the paused status and exits. The pause takes effect on the next read, which is deterministic and inspectable, rather than depending on whether a cancellation reached every queued job.

Duplicate entry merges

A second form submission from an existing contact does not start a parallel sequence. It matches on the identity fields, writes the new information to the existing record, and records the second touch. Two sequences running against one person is the same class of bug as two invoices for one order.

What This Costs You

More moving parts than a chain of timers. A state record per contact, a lock, a send log, and a reconciliation job. That is real work and it is not free.

What you get is a sequence you can answer questions about. Where is this contact. Why did they stop. Did they get step four. Did anyone get step four twice. A timed chain cannot answer any of those, which is usually discovered at the moment someone asks.

How I Approach a Build Like This

• Write down every event that can happen between two steps, before designing either step
• Make state explicit and inspectable, never implied by a pending timer
• Make every side effect idempotent on a key you can reconstruct
• Prefer a check on the next read over a cancellation that has to reach everything
• Add a stuck-record report on day one, because the failure mode here is silence