If someone on your team opened Shopify Flow this week and found they could read a workflow but not switch it on, that is the new permission model, not a bug. Flow moved onto Shopify's admin staff permissions on 28 October. The practical effect: the ability to create, edit, activate or deactivate a workflow is now a permission you grant a staff account in the admin, the same way you grant access to orders or discounts. Give it to the people who need it before Black Friday, because the person you assumed would flip the switch on your backorder automation at 6am on the 28th may no longer be able to.
For Canadian merchants this is awkward timing. Black Friday into Cyber Monday, then a short breath, then Boxing Day. Six weeks where a dead automation costs real money, and where half the people touching the store are seasonal or external.
What the Flow permission change actually does
Before, access to Flow rode along with app access. If a staff account could get into the apps section, it could usually get into Flow and do whatever Flow allowed. That was blunt, and it meant a part-time hire who needed to look at a draft order could also deactivate the workflow that tags high-risk orders for manual review.
Now Flow sits in the staff permission list as its own line. Accounts that had de facto access through app permissions do not automatically inherit the new one. That is where the silent breakage comes from — nothing announces itself, the workflow list still loads, and the failure only shows up at the moment someone tries to change something.
Go and look at it yourself rather than taking my description of the labels on faith. Settings, Users, pick a staff member, and read the permission list top to bottom. Shopify adjusts the wording of these entries more often than you would expect, and the exact phrasing in your admin today is the one that matters.
One more thing, because the search results are muddled: people are typing "Flow app permission change 2026" and landing on this. There is one change, it is the October one, and the reason it feels like a 2026 problem is that the permission sets you configure now are what your team lives with through next year's planning cycle. Set them properly once.
Why your staff can't turn on a Shopify Flow
Four causes, in the order we actually find them:
- The account has no Flow permission at all. Workflows render, the toggle refuses. Most common.
- The account is a collaborator (an agency or freelancer) and the collaborator request was approved before the change, with a scope that never included Flow.
- The workflow uses an action from a third-party app the staff member cannot access. Flow will let you edit around it but the run fails or the step is unavailable.
- The workflow was built by someone who has since left and the connection it depends on — a Slack channel, an email sender, an external HTTP endpoint — was authorised under their account.
That last one is the expensive one. Permissions you can fix in ninety seconds. A workflow whose Slack action authenticated through a departed contractor's account is a rebuild, and you find out on the day it was supposed to fire.
Audit your workflow owners before BFCM
Do this as a half-hour job, not a project. Open Flow, export or screenshot the full workflow list, and for each active workflow write down three things: who built it, which apps it touches, and what breaks commercially if it stops. Then sort by that third column.
A Canadian store's top of that list usually looks something like this. The Canada Post disruption fallback — tag orders above a weight or destination threshold and route them to Purolator or UPS instead. The inventory workflow that hides or unpublishes a product when a size runs to zero, so you are not selling Boxing Day stock you do not have. Province-level order tagging where your 3PL or accounting export needs HST versus GST plus PST split cleanly. The French-language customer tagging for Quebec orders, which for a lot of merchants is now feeding a Bill 96 obligation rather than a nice-to-have.
Here is why the Canada Post one earns its spot. Say you ship 450 orders a day in the Black Friday window and Canada Post normally carries 40% of them. That is 180 orders a day that need rerouting if service is disrupted. Reroute each one by hand — open the order, check the postal code, re-tag, tell the 3PL — and at three minutes an order you have burned 540 minutes. Nine hours. Per day. For one person doing nothing else. The workflow does it in the background and the only thing standing between you and those nine hours is whether the account that was meant to activate it has permission.
Giving an agency Flow access safely
We get asked for Flow access constantly and we would rather it came with limits. What good looks like:
Use a collaborator account, not a staff seat with your agency's shared inbox on it. Collaborator requests carry a scope, the scope is visible to you, and revoking it is one click that does not cost you a staff slot. If your agency asks for a full owner-level staff account for routine Flow work, ask why.
Grant Flow plus only the permissions the workflows actually touch. A workflow that tags orders needs order access. It does not need customer PII export, payouts, or the ability to edit your Shop Pay settings. Most of our Flow work for Canadian clients needs orders, products and inventory, and nothing else.
Agree an activation protocol in writing before peak. Ours is simple: the agency builds and tests, the merchant activates. One named person on your side owns the switch for BFCM and Boxing Day, and that person's permissions get verified in October, not on the day. If you want an outside team doing the activating too, say so explicitly and grant it explicitly.
And put a review date on it. January 15th, revoke everything the project no longer needs. Nobody remembers to do this, which is why so many stores we audit still have active access for a developer who finished a theme job two Christmases ago.
Seasonal hires and the permission set you build once
Canadian retail staffs up in November and sheds people in January. If you are creating staff accounts one at a time and ticking boxes from memory, you will get it wrong — we do, on the first pass, more often than we would like to admit, usually by granting too much.
Define two profiles before you hire anyone:
Seasonal fulfilment / support. Orders, draft orders, customers, no Flow. They need to read what the automation did, not change it. If a workflow misfires on a shift, the escalation is a message to the person who owns Flow, not a toggle.
Ops lead. Flow permission, inventory, products, orders. One or two people, maximum, and both of them employees rather than temps. These are the accounts that activate the Boxing Day price-change workflows and the post-peak clean-up.
Then write both down somewhere your ops manager can find them in December without asking you. A short internal doc beats institutional memory every single time, particularly when the person with the memory is on holiday between the 24th and the 2nd.
Flow access across a Shopify Plus organisation
Plus adds a layer. You have organisation-level users and store-level access, and a user can hold a role at the organisation that does not automatically translate into Flow rights on every store underneath it. Merchants running a .ca and a .com store to handle cross-border duty and de minimis differences hit this immediately: the workflow that stamps US-bound orders with duty-paid handling lives on one store, the person who needs to activate it holds their permission on the other.
Check each store individually. Organisation admin does not mean what people assume it means, and the assumption only surfaces when a workflow needs activating at an inconvenient hour. If you are managing several storefronts and the permission matrix has got away from you, that is usually a sign the org structure needs tidying as much as the permissions do — our Canadian Plus work starts with that mapping more often than with code.
How to test a workflow when you hit a permission error
Testing is where the new model bites hardest, because testing requires activation. A workflow that is off does not run, so "I'll test it on a draft order" only works if you can turn it on first.
The sequence that works:
- Confirm the account has the Flow permission. If the toggle is greyed, stop and fix that — no amount of workflow debugging helps.
- Build the workflow with a tight trigger condition first: order total under $1, or a tag like flowtest-nov. Activate it. It is live but it can only catch your own test orders.
- Place a real order through checkout, including Shop Pay if the workflow branches on payment method, because a draft order does not exercise the same fields.
- Read the run log. Flow records each run and the step it failed at. "App action unavailable" means a permission or app-scope problem. "Condition not met" means your logic, not your access.
- Widen the trigger condition and leave it live.
Do this in the week after Remembrance Day. Not the week of the 24th, when a test order placed against live inventory and a live Canada Post rate card can cause a mess you then have to unpick.
Where Flow stops and something else starts
Permissions are the small problem. The larger one is merchants pushing Flow past what it was built for. Flow is good at tagging, notifying, hiding products, triggering emails and moving data between apps that already expose actions. It is poor at anything needing a loop, a lookup across many records, or a calculation it cannot express in a condition. Province-specific tax logic beyond tagging, bilingual content switching, carrier rate comparison at checkout — those are app or function territory, and bolting them onto Flow produces workflows nobody dares touch, which is exactly how you end up with a critical automation owned by someone who left in August. When we see that pattern we usually pull the logic out into a small private app and leave Flow doing what Flow is good at.
Quick answers
Does the change affect workflows that are already live? Running workflows keep running. The permission governs who can change them. The risk is editing and activating, not execution.
Can a collaborator account hold the Flow permission? Yes, if the scope you approve includes it. Older collaborator approvals generally do not, so re-check rather than assume.
Who should own Flow in a small team? One employee, with a named backup who also holds the permission. Single points of failure and Boxing Day do not mix.
Do I need Plus for Flow? No. Flow is available to merchants on standard Shopify plans, which is precisely why this permission change touches far more stores than the Plus-only crowd.
Open Settings, Users, and read the Flow line on every account that will be near the store in November. Fifteen minutes now, or a 6am phone call on the 28th.