Product
One workspace for every customer conversation and next action.
Product
One workspace for every customer conversation and next action.
Channels
Meet customers on the channels they already use.
Channels
Meet customers on the channels they already use.
Solutions
Start with the customer outcome your team is responsible for.
Solutions
Start with the customer outcome your team is responsible for.
Industries
See DripTell through the real conversations in your industry.
Industries
See DripTell through the real conversations in your industry.
Give every trigger a stable event identity and decide whether the workflow may process it more than once. Then define which updates can start a new run, which states end the journey and how a person can recover a legitimate event that was blocked.
A loop often begins when a workflow updates the same field that triggered it, sends a webhook that returns as a new event or reacts to its own message. Draw one complete cycle and mark every write, webhook and message that can produce another trigger.
Store a provider event identifier or create a deterministic key from the source record, event type and version. Check that key before performing a side effect such as sending a message or updating a deal. Mark it processed only through an atomic operation so simultaneous workers cannot both continue.
Decide whether a contact can enter the workflow again and what new evidence is required. A completed order, closed case, customer reply or manual takeover can be a terminal state. A cooldown can reduce noise, but it should not replace event identity because the same event may return after the cooldown ends.
Set a maximum number of actions for one customer and one time window. Alert the team when the limit is reached, keep the rejected event and offer a controlled replay after the cause is fixed. Do not silently discard every repeated event because a genuine retry may contain the only successful delivery.
Watch duplicate event blocks, repeated state transitions, unusually fast message sequences and workflows that reach their action limit. Compare the blocked event with its source so the team can distinguish a working safeguard from a rule that is rejecting valid customer activity.
No. A cooldown limits frequency but the same event can return later. Use a stable event identity, reentry rules and terminal states as well.
Acknowledge it safely, avoid repeating the business effect and record why it was blocked. Keep a reviewed replay path for valid recovery work.
Alert on repeated transitions, fast message bursts, duplicate event blocks and workflows reaching a per customer action limit.
Bring one real event chain, its retries and the fields it updates. DripTell can help identify the reentry and recovery rules.