StoreBuilt reviewed Shopify’s current Flow troubleshooting guidance alongside our automation-governance playbook. The practical distinction is between a workflow that never started and a workflow that started but did not produce the expected result. Our investigation method follows one affected record through the run evidence before changing the automation or replaying its actions.
When a Shopify Flow workflow is not running, a UK ecommerce team might notice a missing tag, an absent internal alert or an order that has not reached another service. Those symptoms do not all point to the same fault. This guide helps you locate the break and define a controlled recovery, while the broader ownership and monitoring policy remains in our Flow governance guide.
In this guide
- Begin with one record and one expected outcome
- Look for a run before interpreting the result
- Verify the event that should start the workflow
- Read conditions using actual run values
- Distinguish temporary failure from an invalid action
- Test the repair without assuming simulation proves delivery
- An illustrative tagging failure
- Plan retries around side effects
- Close the incident with an observable outcome
- StoreBuilt point of view
Begin with one record and one expected outcome
Choose a single affected order, product or customer and write down the action you expected. Include the relevant event time and the workflow name. Avoid starting with a screenshot of the whole automation canvas: it shows intended logic, not necessarily what happened to this record.
Find a successful comparison if one exists. A recent order that received the correct tag can reveal a difference in customer state, event timing or input values. Keep the comparison narrow. If you compare two records with different products, payment states and apps, the investigation becomes a list of guesses instead of a test.
Look for a run before interpreting the result
Shopify provides workflow run history showing what executed. Locate the relevant run and read its steps. If you cannot find one, verify the search scope, event timing and workflow activation before concluding that an action failed.
Completed run history has a limited retention period, so preserve useful evidence promptly and avoid treating missing old history as proof that nothing happened. Store only the information needed for diagnosis. An order reference, step result and error message can be enough; copying an entire customer’s record into a general incident document usually adds noise.
| Evidence | Interpretation to investigate | Next action |
|---|---|---|
| No matching run found | Trigger, activation or search scope | Verify the event and workflow |
| Run follows a false branch | Condition did not match | Compare actual values and operators |
| Run is still running | Wait, retry or resource constraint | Inspect the current step |
| Run failed | A step reported an error | Read the exact error details |
| Action succeeded, outcome absent | Downstream or expectation mismatch | Check the receiving system |
Verify the event that should start the workflow
Match the business event to the actual trigger. An order being created and an order being paid are not interchangeable events. If the expected data becomes available later, the workflow may be starting before the information needed by a condition exists. Review the trigger’s documentation rather than adding arbitrary waits everywhere.
Shopify’s workflow creation guidance notes that some fields may not be populated when a workflow runs. A better trigger can be more reliable than a guessed delay. Document why the chosen trigger provides the data your action needs, and test both the usual path and an order that reaches that state later.
Read conditions using actual run values
Open the step that decided whether to continue. Compare the actual input with the condition, including the operator and whether the field is missing, empty, a single value or a list. A condition evaluating false is not necessarily a platform error; it may be doing exactly what was configured.
Write the intended business rule in ordinary language next to the technical condition. For example, “any line belongs to the eligible range” differs from “every line belongs to the eligible range”. A mixed basket is a useful control for this distinction. Preserve both the expected result and the actual branch taken so that a reviewer can assess the change.
Distinguish temporary failure from an invalid action
Shopify’s troubleshooting guidance separates transient and permanent errors. Temporary connector failures can be retried by the system, while an invalid action may require correction. Read the current step and error message before restarting a run that is still working through a retry.
Check the receiving app’s status and the connection used by that action. A workflow can be structurally valid while an external service rejects a request or has lost access. Give the provider the specific error and affected operation, with secrets removed. Do not paste access tokens into a support ticket or replace credentials without understanding which other workflows use the same connection.
Test the repair without assuming simulation proves delivery
Use Shopify’s workflow testing feature where appropriate to inspect how sample event data moves through the logic. Test a positive case, a negative case and a record with the field missing. This catches conditions that work only for the example used while building the automation.
Some external actions cannot be fully simulated. A configuration preview is not evidence that the destination received a message or changed a record. For those actions, plan a controlled live test with an appropriate test record and check the receiving system. Our Shopify development service can help isolate the integration boundary and define the evidence needed to approve it.
An illustrative tagging failure
Imagine a British homewares retailer expects orders containing a made-to-order item to receive an operations tag. Single-item orders work, but mixed baskets do not. The run exists and completes without an error. Inspection shows that the condition describes all lines belonging to the range, although the business wanted any matching line to qualify.
The team corrects the condition and tests three baskets: only standard products, only made-to-order products and a mixture. It then reviews affected historical orders before planning recovery. This is an illustrative scenario, not a claim about a client. Its lesson is that a successful run can still express the wrong business rule; looking only for red error markers would miss the problem.
Plan retries around side effects
Before retrying, list the actions that already succeeded. Adding a tag may be straightforward to reconcile, while creating an external task, sending a message or changing an operational state may produce duplicates. Establish how each action identifies work that has already happened.
Do not assume a retry is equivalent to continuing safely from the point you had in mind. Review Shopify’s current retry behaviour for the workflow and inspect the proposed recovery. Start with one affected record, verify the result at the destination and only then consider the remaining population. Separate the number of records reviewed, selected for replay and successfully reconciled.
| Recovery check | Evidence required | Stop condition |
|---|---|---|
| Corrected logic | Positive and negative test results | Wrong branch still taken |
| Existing side effects | Destination record or action history | Duplicate risk unexplained |
| One-record retry | Expected final state | Unexpected external action |
| Wider recovery scope | Explicit affected record list | Unrelated records included |
| Post-recovery review | Source and destination agree | Partial or ambiguous result |
Close the incident with an observable outcome
A fixed canvas is not the final deliverable. Confirm that a fresh qualifying event now produces the expected result and that an ineligible event does not. Check the actual tag, external record or operational change. Keep the incident note concise enough that the next person can reproduce the verification.
Add an owner and a monitoring route for the failure that occurred. Error alerts help with explicit failures, but a false condition may complete cleanly and therefore require outcome sampling. Review a small number of representative records after the next promotion or integration change. This is a better signal than assuming that the absence of error notifications means every business expectation was met.
StoreBuilt point of view
Automation should make an operational promise observable. StoreBuilt diagnoses Flow by connecting the event, the run, the branch and the downstream result. Repair the logic that fails, verify the effect where it matters and replay historical work only when its existing side effects are understood. That approach makes recovery more dependable than repeatedly pressing retry.