Preventing signal loops

The classic loop: a step sends correspondence from the case, the shared inbox receives a copy, the inbound-correspondence signal fires, the step runs again.

How the platform limits the damage

A signal firing more than fifty times in a minute for a single case is throttled, and the throttle is logged under Signals → Activity. That stops runaway sending but it does not stop the loop — you still have to break it.

Breaking it

Exclude your own addresses. In the inbox integration, add the shared address to the ignore list. Correspondence the platform sent stops triggering inbound signals. This is the fix for the classic case and takes a minute.

Condition the step. Add a condition so the step only runs when the case is in a particular stage. A loop needs the trigger to be satisfiable repeatedly; a stage condition usually is not.

Use a once-per-case guard. Steps can be set to run at most once per case. Right for acknowledgements, wrong for chasers.

Finding an existing loop

Sort Signals → Activity by case. A loop shows as one case with hundreds of entries where every other case has a handful. Throttled entries are marked, so a case that has been throttled is where to look first.

Testing a new step

Run it against one case type with a small caseload for a few days before rolling wider. A loop on three cases is an afternoon; a loop on three thousand is a conversation with your customers.