Duplicate follow-ups

Sameness is decided on two things: the person, and the *when*. A follow-up with the same due time for the same person is a duplicate and the second is not created. Channel and reason are not part of the test — which keeps the rule easy to reason about, and means two genuinely different promises due at the same instant will collide.

Status: Available What this means
Audience: both
In the app: #/follow-ups
Last verified: 2026-09-10
Product version: 6.3.2

The rule, stated plainly#

Same person, same *when*, therefore duplicate. That is the whole test. It is narrow on purpose: a rule that also compared the wording of the reason would have to decide whether "ring about the order" and "call regarding the order" are the same promise, and any answer it gave would be wrong often enough to be worse than no rule.

Situation	Caught?	Why
The same call booked twice in one conversation	Yes	Same person, same time — the second attempt does not create a row
A person and the voice both booking the same call-back	Yes, if the times match exactly	The rule does not care who created either row
Two rows a minute apart for one promise	No	The times differ, so they are two commitments as far as the rule is concerned
Two different promises due at the same instant	Yes — and this is the awkward case	Sameness is the time, not the content
The same promise to two people at one company	No	Different people, different commitments, correctly

Why the person and not the address#

A follow-up hangs off the canonical Person, not off an email address or a number. That is what makes the rule useful in a system where one human holds many identities: a call-back promised on a WhatsApp thread and the same call-back promised by email are one person's commitment, and the rule sees them as such.

It also means the rule improves when your records do. Two rows that were not duplicates because they hung from two Person records become detectable as one after those records are merged — a merge preserves the follow-ups from both sides, so the survivor is where you go looking for the pair.

The collision case, and what to do about it#

The honest cost of a rule this simple: if you promise somebody two different things at three o'clock on Thursday, the second row is treated as a duplicate of the first. Nothing is lost silently — you find out at the moment of creating it — but the second commitment needs somewhere to go.

Give the second commitment its own time.
Result Two rows exist, both due around when you meant, and each can be completed on its own. Five minutes apart is enough.
Or fold both into one row with a reason that names both promises.
Result One action keeps both, which is often what actually happens on the call anyway.
If one of them is human work, put it on task with its own time.
Result The message and the work behind it stop competing for the same slot, and the work is visible to whoever is doing it.

When duplicates still appear#

Times that differ by seconds: Two bookings made moments apart from a relative phrase — "in ten minutes", twice — resolve to different instants and are two rows. Read them together and cancel the redundant one.
Two Person records for one human: The commonest real cause. Until the records are merged, the rule cannot know they are the same person; duplicates on the relationship console proposes the pair, and merging is a person's decision.
A cancelled row re-created: Cancelling and immediately re-creating at a new time is not a duplicate and should not be — but it is worth asking whether an edit would have been the better move.
Rows on different channels: Channel is not part of the test, so an email chase and a phone chase at the same instant for one person collide. Separate them in time or in intent.

Questions#

What happens to the second row — is it rejected or silently dropped?

It is not created, and you are told at that point rather than discovering it later. The existing row stands, with its original reason, which is the safer of the two outcomes: the older reason is the one written closest to the promise.

Does the rule stop the drain executing something twice?

That is a different protection. The duplicate rule is about creating rows; what stops one commitment being acted on twice is the row's own recorded outcome, which is written back when the attempt is made.

Can I deliberately schedule two follow-ups at the same minute?

For the same person, no — that is precisely what the rule refuses. For two different people, yes, and they are separate commitments in every respect.