Workflow SuiteWorkflow Suite

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.

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.
  • 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.
  • 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.

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.