--- title: "Loop protection - Workflow Suite" description: "What Workflow Suite does to keep workflows from triggering themselves in circles, what it cannot know, and how to build workflows that do not loop." canonical: "https://docs.workflow-suite.app/loop-protection" --- # Loop protection The classic loop: a workflow starts on **Product updated**, updates the product, and that update starts the workflow again. Forever, and on your plan's account. Loop protection is built in and always on. This page says exactly what it does, and what it cannot know. ## Three layers **1. It recognises the echo of its own change.** When a step changes something in your store, the run notes which resources it changed. If an event for one of those resources arrives within about 30 seconds, it is treated as the echo of that run, and it carries the chain of workflows that led to it. A workflow that is already in that chain is not started again. That stops a workflow triggering itself, and it stops A starting B starting A at the first repeat. **2. It limits chains.** Workflows may trigger each other on purpose: A changes a product, B reacts to that. Such a chain of different workflows ends after 5 workflows. **3. It turns off a workflow that fires too often for one resource.** If one workflow starts more than 10 times within 60 seconds for the same resource, the app turns the workflow off, whatever the cause. You get an alert, and the editor shows **This workflow was turned off automatically** with the reason. This one is the backstop for everything the first two layers cannot see. ## What you see A run that loop protection stopped is kept in the run history with the status **Not started** and the reason, so you can see why nothing happened. No step ran. Such runs do not count against your plan. A run's page also shows **Started by a chain of workflows** when other workflows led to it. > [!WARNING] > **What it cannot know** > The first layer works with a time window, not with proof. Two consequences: > > - **An edit by hand can be taken for an echo.** If you, a colleague or another app changes a resource within about 30 seconds of a workflow's change to the same resource, that event can be attributed to the workflow and not start it again. > - **A late echo is not recognised.** If Shopify delivers the event of a workflow's own change later than the window, it looks like any other event. Then the third layer is what ends a loop. > > So loop protection limits the damage of a loop. It does not replace building workflows that do not loop in the first place. ## Build workflows that do not loop - **Use a change trigger instead of an updated event.** **Product tags added** with a filter on one tag does not start again when your workflow changes the product's status. See [Change triggers with before and after values](https://docs.workflow-suite.app/change-triggers.md). - **Filter on what you are about to change.** A workflow that adds the tag `sale` should only start, or only continue, when the product does not have the tag yet. Then its own change cannot pass the filter a second time. See [Trigger filters](https://docs.workflow-suite.app/trigger-filters.md). - **Make the change idempotent.** Adding a tag that is already there, or setting a status that is already set, changes nothing in Shopify and so causes no new event. - **Do not let two workflows correct each other.** If A sets a field whenever B changed it and B does the reverse, that is a loop by design. Put the logic into one workflow. ## Which changes are noted Changes made through ready-made Shopify actions, the Shopify Admin API (GraphQL) step, the Liquid script step's actions, and `ctx.shopify` in code are noted. A change your workflow causes through another system, for example an HTTP request to an ERP that then writes to Shopify, is not: the app cannot see that connection. Only the third layer covers that case. ## Triggers without a resource The echo check and the turn-off rule work per resource, so they apply to events that are about one resource: a product, an order, a customer. Schedules, incoming webhooks and storefront behaviour triggers have none. For storefront triggers that is on purpose: ten shoppers viewing one product within a minute is not a loop. ## Start another workflow A workflow cannot start itself with the **Start another workflow** step, directly or through other workflows. That start is refused and the step fails. See [Manual runs and workflows started by another workflow](https://docs.workflow-suite.app/manual-runs-and-started-by-another-workflow.md). ## After a workflow was turned off 1. Open the workflow. The banner names the reason. 2. Open its **Run history** and look at the runs just before: which resource, what started each run. 3. Fix the cause, usually with a filter as described above. 4. Select **Turn on**. ## Related - [Alerts by email and text message](https://docs.workflow-suite.app/alerts.md) - [Run history and troubleshooting](https://docs.workflow-suite.app/run-history-and-troubleshooting.md)