Prevent automations from triggering themselves repeatedly

Find the field that starts each run

Order execution history for one intake identifier and connect the original edit, condition evaluation, changed fields and subsequent run. Message count alone cannot distinguish upstream duplicates from an internal update loop. Check which identity wrote each field and whether that write created the next trigger. Two automations can also trigger one another, so inspect every writer to the same table. The useful diagnostic artifact is a short causal chain of edits and runs, not a screenshot showing only that several executions failed.

Distinguish a transition from a state

Being Complete and changing from Open to Complete are different conditions. Specify the transition that deserves notification and avoid writing the same target value repeatedly. Check whether the active trigger observes entry into a condition or every update to selected fields. Also decide whether a reopened request should notify again when completed a second time. A single permanent sent flag can suppress a legitimate later transition, so the record of processed work must match the business event you actually intend to handle.

Keep processing markers out of the trigger

Consider separating the human-entered status, machine processing state and delivery result. A timestamp written only to record success should not unnecessarily become the same trigger’s watched input. Separation makes causes clearer but is not by itself a concurrency lock. Check whether simultaneous runs can process the same event and define recovery when a Processing marker remains after failure. An operator should know what evidence permits clearing it, rather than resetting every marked row and creating another burst of messages.

Pause the loop without losing intake

Pause the smallest affected workflow or delivery path while preserving legitimate incoming work. Deleting intake to quiet the system removes the evidence needed for recovery. Record the pause interval, unfinished identifiers and already delivered notifications before deciding where to resume. Do not replay everything merely because the trigger rule has changed, especially when an external message may already have been sent. Separate unwanted repetitions from new valid requests and make sure operators can still locate intake arriving during the pause.

Verify interacting workflows together

Test the result-field write, a human note edit and the interaction of two workflows, not only a single intended status change. Specify notification counts and final states in advance using fictional data. Inspect execution history to confirm that fewer notifications did not come from suppressing required work. A changed trigger rule does not necessarily process historical matching records, so handle any backlog as a separate controlled task. Do not use existing customers as test recipients merely to find out which edits start the workflow.

Define the notification unit for future changes

Acceptance requires a record of which business transition a notification represents, not only its intake identifier. Keep that unit in processing records so a later repeated edit can be classified correctly. When adding fields or workflows, review whether watched inputs and written outputs form a cycle. External redelivery remains a separate problem even after internal loops stop; use the related webhook guide for idempotency. The lead-intake guide covers assignment and response tracking beyond the narrower task of preventing self-triggered repetition.

• Choose webhook automation around duplicates, order and replay
• Automate lead capture from receipt to accountable follow-up