Shopify Flow : View who edited, activated, or deactivated a workflow version.

Why “who changed this Flow ?” matters more than you think

In a busy Shopify store, Shopify Flow quietly becomes the nervous system.

A single edit can change how orders get tagged, which orders get held for fraud review, which fulfillment location gets used, who gets notified, whether a VIP discount is applied, or whether your team gets pinged in Slack at 2am for every single order. And when something goes wrong, the symptoms are usually… weird. Not “site is down” obvious. More like :

• Orders stopped getting tagged, so your warehouse can’t batch pick anymore.
• Email notifications randomly stopped.
• Slack is spamming 400 messages an hour because someone removed a condition.
• Fraud holds got removed, and now risky orders are sailing through.
• Fulfillment routing changed, and suddenly everything is going to the wrong location.
• A discount action started triggering for the wrong customers.

When that happens, everyone asks the same question. Who changed this Flow ?

This is not about blame. It’s about two things that matter during an incident :

1. Accountability (so changes aren’t “mystery events”).
2. Faster debugging (so you stop guessing and start checking the actual change history).

The goal of this guide is simple : show you how to quickly view who edited, activated, or deactivated a workflow version, and how to use that info to troubleshoot without making the problem worse.

Quick primer : workflows, versions, and statuses in Shopify Flow

Before we jump into where to click, it helps to be clear on what Flow is tracking.

What a workflow is (plain English)

A workflow in Shopify Flow is basically :

• A trigger (something happens, like “Order created”)
• Optional conditions (only if X is true)
• Actions (do something, like tag the order, send email, post to Slack, hold fulfillment, etc.)

So it’s “when this happens, if this is true, then do that”.

What versions are

Every time you change a workflow and save it, you’re effectively creating a new version of that workflow. You can think of versions as snapshots over time.

That matters because during an incident you’re not just trying to see what the workflow looks like right now. You’re trying to answer :

• What did it look like before things broke ?
• When did it change ?
• Who changed it ?

Version history is where those answers usually live.

Shopify Refunds : Apply Discounts on the Refund Page

Refunds get weird fast when the original order had a discount.

EnovaiZakia

What statuses are (activated vs deactivated)

Flow workflows also have a status, typically :

• Activated (active) : the workflow is live. It will run when the trigger happens.
• Deactivated (inactive) : the workflow is off. Nothing runs.

Activation is basically a release moment. Like deploying a change.

Edited vs activated vs deactivated, what it usually means during incidents

When something breaks, these three events give you different clues :

• Edited : someone changed the logic. Could be harmless. Could be the whole cause.
• Activated : someone pushed it live (or reactivated it). Often the moment the problem started.
• Deactivated : someone shut it off. Sometimes as a quick fix, sometimes by accident.

Version details help you correlate changes with business impact. The time window, the editor, and what changed. That trio is what you want.

Where to look in Shopify Flow to see who edited/activated/deactivated a version

High level navigation, starting from Shopify admin :

Shopify admin → Apps → Flow → Workflows → select the workflow

Once you're in a workflow, there are a few UI areas worth scanning (names can vary a bit as Shopify updates things, but the idea stays the same) :

1. Workflow details page : usually shows the current status (active/inactive) and basic info.
2. Version history / activity area : where versions and "updated by" details tend to appear.
3. Run history / activity logs (when relevant) : helps confirm what the workflow actually did, and when it started behaving differently.

Before you change anything, capture a few facts. Seriously, do this first. Write it down or paste into your incident ticket.

• Workflow name
• Current status (active/inactive)
• Current version (or most recent version entry you can see)
• Timestamps around recent changes
• The user/account shown as the editor/actor

Tip for teams : open the workflow in a new tab and avoid making edits while investigating. It's too easy to accidentally save, create another version, and muddy the timeline.

Step-by-step : view the version history and identify the actor

Because Shopify UI shifts over time, the wording below is kept generic, but you'll recognize it when you see it.

1. Open Flow — go to Shopify admin → Apps → Flow.
2. Go to Workflows — find the workflow involved in the incident. Search by name if you have a lot.
3. Open the workflow — you should land on a page showing the flow diagram and details.
4. Locate the versions/history panel — look for a label like Versions, Version history, or Activity. In some layouts it appears as a tab near the top; in others it's a panel on the workflow details screen.
5. Identify the key fields — in the version list or history entries, look for : the timestamp (when the version was created or the change occurred), the status (active/inactive or an activation indicator), the "Updated by" or "Edited by" field (the user or account responsible), and sometimes a version number, label, or "current" marker.
6. Tell saved edits apart from activation events — a saved edit means the workflow logic was modified and saved. An activation event means the workflow was put into an active state, or a specific version became the live one. A deactivation event means the workflow stopped running entirely. If your incident is "nothing is happening anymore", deactivation is your prime suspect. If your incident is "it's doing the wrong thing", look at activation or edit timing.
7. If multiple edits happened, work backward — start with the most recent active version if the workflow is currently active, or the last active version if it's currently inactive. Work backward through earlier versions until you find the change that lines up with the incident start time.

How to confirm whether the current live workflow matches the last activated version

This is where teams get tripped up.

A common confusion is assuming "what I see on the canvas" equals "what's live". Depending on Flow behavior and how your team works, you can end up with edits that exist after the last activation, or changes that were saved but the workflow is currently inactive.

Here's a safe way to think about it :

Step 1 : Confirm the workflow's current status

On the workflow details page, verify whether the workflow is Active or Inactive.

Step 2 : Confirm which version is live

In version history, look for an indicator of the current version, or the version tied to the most recent activation event.

Step 3 : If the workflow is deactivated

• Identify the deactivation event.
• Note who deactivated it and when.
• Identify the last active version before deactivation — that is usually the last known running state.

Step 4 : If edits exist after activation

Treat them as pending until you confirm they reflect actual live behavior. During an incident, assume the last activation event is the "release" and that anything after it may be a draft, partial, or unrelated to when things went wrong.

If you're unsure, use the activity/run logs to confirm when the workflow started executing differently. That gives you a hard timestamp to match against version events.

Shopify “Delivered” Without Tracking: What Actually Works

Learn how to mark untracked Shopify orders as delivered for local drop-offs, hand deliveries, and freight shipments.

EnovaiZakia

What to do with the info : a practical incident workflow (without breaking things)

Once you've got the "who and when", you need a process that doesn't create new chaos.

Here's a simple incident workflow that works well for most teams :

1. Identify the incident start time. When did you first notice the symptom ? When did the first "bad" order happen ?
2. Check version events around that window. Look at edits, activations, and deactivations within that time range.
3. Correlate with store impact. Match workflow changes to what changed in the business. For example : tags missing starting at 10:12am, Slack spam starting at 3:40pm, or fraud holds stopping overnight.
4. Decide : rollback vs fix forward. If it's clearly a bad change and you have a known good prior version, rollback is usually fastest. If it's a small logic bug and you understand it, fixing forward may be fine. The key is not to experiment in production while orders are flying in.
5. Message the editor. Keep it neutral and fact-based. Ask something like : "Hey, I see Workflow X was activated/edited at 2:14pm by you. Was this tied to a ticket or a planned change ?" Ask for intent, a link to a ticket, or a reason for the change. Assume good intent — even if it was a mistake, you want clarity, not a fight.
6. Document what you found. Screenshot the version history entry showing who made the change and when. Add it to the incident note. This is gold later.

Common scenarios and how version attribution speeds up debugging

Scenario 1 : Workflow was deactivated

Symptom : orders stopped being tagged, emails stopped, nothing is running.

What you do :

• Check the workflow status (inactive).
• In version history/activity, find the deactivation event.
• Note who did it and when.
• Decide whether to reactivate immediately, or first confirm why it was turned off (sometimes it was intentionally paused to stop damage).

This is one of those “five minutes to solve” problems if you can see attribution.

Scenario 2 : Workflow activated with a bad condition

Symptom : sudden surge or sudden stop in actions.

• Surge example : Slack gets hammered because “Order created” now posts without any filters.
• Stop example : a condition changed from “contains” to “equals” and now nothing matches.

What you do :

• Find the most recent activation event.
• Identify who activated it and the timestamp.
• Compare the workflow logic with what you expected.
• If you need to fix, do it deliberately. One change, one test, then activate.

Scenario 3 : Multiple team members edited the workflow

Symptom : nobody is sure what happened, because three people touched it this week.

What you do :

• Use timestamps to narrow the change window to the first bad order or first missing tag.
• Ignore unrelated edits outside the window.
• Start with the most recent active version, then walk backward until you hit a version created right before the incident.

This is where version history turns a vague argument into a timeline.

Scenario 4 : Agency or collaborator access

Symptom : your internal team swears nobody touched it.

What you do :

• Check whether the actor is a staff user, a collaborator, an agency login, or sometimes an app integration (if shown in your admin context).
• Confirm whether there was planned work (theme, checkout, fulfillment) that might have included Flow updates.
• If you’re working with external partners, this is also your cue to tighten access and require change notes.

Shopify: Track “Not for Sale” Inventory (No Hacks)

You’ve got stuff in your building that absolutely counts as inventory. It’s real. It’s sitting on a shelf. You paid for it (or made it). But you do not want customers to buy it. And you do not want your fulfillment team to ship it.

EnovaiZakia

Best practices to prevent “mystery edits” in Shopify Flow

You don’t need heavy process. You need just enough to stop silent production changes.

Limit access (least privilege)

Only give Flow editing rights to people who truly need it. View only access is fine for most roles that just need visibility.

Also, be careful with shared accounts. If three people use the same login, “who changed it ?” becomes unanswerable. Even if the tool shows a name, your process needs to support it.

Change management that doesn’t feel like change management

Require a short note in your internal system whenever someone changes a high impact workflow. Not a novel. Just :

• workflow name
• what changed
• why it changed
• link to ticket/request

Where to keep it ? Anywhere your team already lives. Notion, Google Sheets, Jira, ClickUp. Pick one. Keep it frictionless.

Attach evidence

When someone activates or deactivates a workflow, ask them to attach a screenshot of the version history entry showing the actor and timestamp. It sounds extra, but it saves hours later.

Review cadence

Quick weekly check for your high impact workflows. Not all of them. Just the ones that can hurt revenue, fulfillment speed, fraud exposure, or customer comms.

Create a lightweight “Flow change log” your team will actually use

If your log feels like homework, nobody will do it. Keep it stupid simple.

Template :

• Date/Time
• Workflow
• Version (or screenshot)
• Change summary
• Who
• Why
• Link to ticket

Where to keep it :

• Notion page titled “Flow Change Log”
• Google Sheet with one tab
• Jira/ClickUp task template field

And set one rule : if you activate or deactivate, you log it. If you only draft something and don’t activate, you can skip it. The log is for what actually changes production behavior.

Wrap-up : the fastest way to answer “who changed this workflow ?”

The fastest way is basically a repeatable little checklist :

1. Open Shopify admin → Apps → Flow → Workflows → select the workflow
2. Check the workflow status (active/inactive)
3. Open version history/activity and find the relevant version event
4. Capture who edited/activated/deactivated and the timestamp
5. Correlate it with the first moment the issue appeared
6. Document it (screenshot + short note) before you touch anything

The outcome is what you want. Faster recovery, clearer accountability, fewer repeated incidents, and less time spent doing detective work in Slack.

Practical next step : review your top 5 most critical workflows today and record the current active version, status, and owner. Just that. If something breaks next week, you’ll be glad you did.

Conclusion

If you take nothing else from this, take this : Shopify Flow incidents are usually timeline problems.

Something changed, and the store started behaving differently. When you can quickly see who edited, who activated, or who deactivated a workflow version, you stop guessing. You can ask the right person the right question, roll back safely, and get orders moving again.

Open the workflow, check the version/history, grab the actor and timestamp, then decide your fix. And next time, keep a tiny change log so “mystery edits” stop being a thing.

FAQs (Frequently Asked Questions)