Shopify B2B on Grow: Why can’t Company Locations be automatically assigned to Markets?

Shopify Discussion
, , , ,
1

I’m hoping someone in the Shopify Community can tell me I’m missing something here, because I’ve now gone through this extensively with Shopify Support and we’ve apparently hit a surprisingly basic limitation.

I run a professional-only beauty supply business on Shopify Grow.

Our customers are licensed/certified beauty professionals. Many are independent professionals rather than traditional companies, but they are still legitimate B2B/professional purchasers.

We currently use a third-party B2B/access-control app, and I’ve been trying to replace it with Shopify’s newer native B2B functionality.

Shopify’s native system is SO close to doing exactly what we need.

The workflow we need is:

Professional submits application + certificate/licence
→ application is pending
→ we review credentials
→ we approve them
→ they receive B2B ordering access
→ they are assigned the appropriate product-access level

We have several different product-access levels because some professional product ranges have additional qualification/approval requirements.

This isn’t primarily about wholesale discounts or different pricing. We need actual PRODUCT ACCESS so that certain products can only be purchased by appropriately qualified and approved professionals.

Shopify already has almost every component needed:

• Shopify Forms Company Account Requests
• Manual B2B approval
• Companies and Company Locations
• Ordering permissions
• Customer Accounts
• B2B Markets
• Catalogs
• Shopify Flow

The problem:

On Grow, catalogs are assigned through B2B Markets.

When creating a Market using Company Locations, Shopify requires the individual Company Locations to be selected.

There appears to be NO Shopify Flow action to:

“Add Company Location to Market”

or

“Remove Company Location from Market”

Market membership also apparently cannot be dynamically determined using a Company/Company Location tag, metafield, segment or approval/access level.

Shopify Support has confirmed to me that Market assignment cannot be automated natively on Grow, and that the missing Flow action doesn’t exist on Plus either.

That means every time we approve a new professional, somebody has to manually maintain their Market membership.

If their product-access permissions change later, somebody has to manually change their Market membership again.

With hundreds or potentially thousands of individually approved professionals, that isn’t a realistic long-term workflow.

The frustrating part is that Shopify has already built 95% of the system.

If Flow simply had:

• Add Company Location to Market
• Remove Company Location from Market

OR if B2B Markets supported dynamic membership based on tags/metafields, the whole system could work.

The other awkward part is Shopify’s assumption that B2B buyers are traditional companies.

Many professional industries don’t work that way. Beauty professionals, dental professionals, medical professionals, tradespeople and other licensed or certified professionals can be independent professional purchasers without operating as a traditional company with multiple employees.

I’m currently having to create each individual professional as essentially a one-person Shopify Company just to access Shopify’s native B2B approval and catalog functionality.

Has anyone found a NATIVE workaround for this that I’m missing?

Specifically:

  1. Is there any way to automatically assign a Company Location to a B2B Market after approval?

  2. Can Market membership be dynamically controlled by a Company Location metafield, tag, segment or another condition?

  3. Is there another way on Grow to securely restrict product access for individual approved professionals without using B2B Markets?

  4. Has anyone built a professional-only Shopify store with multiple product-access levels without relying on another paid B2B/access-control app?

I’m specifically looking for a native Shopify solution if one exists, rather than another app recommendation.

I moved to Shopify partly to simplify our technology stack, and I’m getting increasingly frustrated by needing additional paid apps to connect functionality that Shopify already largely provides.

At this point I’m keeping our existing third-party access system running, but I’m also starting to look at other ecommerce platforms because I don’t want to keep adding paid apps for functionality that should reasonably be part of the platform.

If I’m overlooking something in Markets, Flow, B2B or Customer Accounts, I would genuinely love to know.

2

I also want to add one more practical issue from the day-to-day store side of this.

At the end of the day, I should not have to give store staff access to every single app installed on my Shopify account just so they can approve a professional registration while the customer is standing in front of them.

That is another permissions gap that makes this harder than it needs to be.

My staff do not need access to accounting apps, purchasing apps, automation apps, reporting tools, or other back-end systems. They simply need limited operational access to things like professional account approvals and barcode tools.

Right now, Shopify’s app permissions appear to be essentially all apps or no apps for that staff user.

For a multi-staff retail business, that is not a practical permission model.

There should be a way to grant a staff role access to specific individual apps only, in the same way Shopify already allows granular permissions for customers, orders, products, inventory, finances, etc.

A staff member standing at the counter should be able to review and approve a professional account without being given access to the rest of the business’s app ecosystem.

Between this and the inability to automate B2B Market assignment, it feels like Shopify has built most of the individual pieces needed for professional-only retail, but the connections and permissions between those pieces are still missing.

3

You’re not missing anything - the lack of an “add/remove Company Location to Market” action in Flow is a real gap, and dynamic Market membership by tag or metafield isn’t supported today either.

One avenue worth testing on a dev store: Flow’s Send HTTP request action can call the Admin GraphQL API directly, so an approval trigger could in principle update Market membership for the newly approved location without adding another app.

It’s also worth filing this in the feature request board, because the one-person-company pattern for licensed professionals comes up in a lot of industries and the use case is well argued here.

4

You are dealing with two separate risks here: the missing assignment step, and the staff-access model around the approval step. I would keep the current access app as the source of truth and test any native replacement in shadow mode before moving hundreds of professionals.

For a 20-account pilot, I would compare:

  • credential status and expected product-access tier,
  • expected Company Location/Market membership,
  • actual membership after approval or a later access change,
  • which staff role performed each step,
  • exceptions that still required owner/admin review.

That catches a workflow that looks automated but assigns the wrong catalog, and it keeps the permissions problem visible instead of treating assignment alone as success.

How many new approvals or access-level changes do you handle in a typical week, and how many product-access tiers are there? A count is enough; please do not post customer names, licence details, or certificates.

5

Your read on the missing Flow action is right, but there is an API-level distinction worth testing before abandoning native B2B. In Shopify’s Admin GraphQL 2026-01 schema, marketUpdate accepts conditions.companyLocationsCondition.companyLocationIds; the MarketConditionsCompanyLocationsInput type explicitly defines that list.

That makes a private automation path possible:

  1. Approval sets the professional’s access-tier metafield or tag.
  2. Flow sends the Company Location ID and tier to a private endpoint.
  3. The endpoint queries the target Market’s current Company Location IDs, adds or removes the approved location, then calls marketUpdate.
  4. It re-queries membership and records an exception if the actual Market does not match the intended tier.

I would not place an Admin API token directly in a Flow request. Keep the token in the private endpoint, validate the incoming request, and give the app only the required company and market scopes. Shopify documents read_markets plus write_markets for Market mutations, and the store still needs B2B access. Test this against the exact API version and plan on a development store first, because some B2B operations remain capability-dependent.

This does not solve the separate staff-permissions problem. I would keep the current approval surface restricted and run a 20-account shadow pilot before replacing the existing access app. If marketUpdate rejects the Company Location condition on Grow, that confirms there is no fully native route for this workflow today.

6

Hello there @divinebeautysupplies
You’re not overlooking an obvious setting. The only restriction is that the Company Location membership in B2B Markets is not yet available as a Flow action or dynamic rule on Grow.

For native I would structure the approval process based on Company Locations and have different catalogs for each level of access, but the end Market assignment still needs to be done manually. Shopify Flow can implement the approval and tagging logic for that process, just not Market membership itself.

Your recommendation for Add/Remove Company Location from Market would nicely bridge this gap, particularly for professional industries with individual purchasers.

7

Thank you, this is exactly the kind of information I was hoping someone here might know.

Shopify Support specifically confirmed to me that there was no native way to automate Company Location → Market assignment, but they didn’t mention the possibility of using marketUpdate through the Admin GraphQL API.

The key question for me is exactly the caveat you mentioned: does marketUpdate actually allow conditions.companyLocationsCondition.companyLocationIds to be updated on a Grow store?

If it does, I would definitely be interested in testing this with a small number of accounts before moving our existing professional customer base.

Ideally, I want the process to be:

Application submitted

→ credentials reviewed

→ staff approves professional

→ access level is set

→ correct Market/catalog access is assigned automatically

→ customer can shop

If the API can bridge that one missing step, Shopify may actually be much closer to supporting our workflow than Support believed.

Do you know whether this has actually been tested successfully on a Grow store, or are you suggesting it based on the current GraphQL schema?

The staff permissions issue would still remain separately, but solving the Market assignment problem would be a significant step forward.

8

That is the right distinction. I have not personally run this mutation on a Grow production store, so I would not call it proven. Shopify’s current docs do show that Grow supports B2B Markets, and Admin GraphQL exposes companyLocationIds plus marketUpdate. But the API docs also warn that some B2B operations can require additional plan capabilities, so schema availability alone does not prove that this mutation will be authorized on your Grow shop.

The lowest-risk test would be one non-production market and one test company location:

  1. Query the current market conditions.
  2. Add only the test company location.
  3. Read the market conditions back and capture any userErrors.
  4. Sign in as the test B2B contact and confirm the expected catalog/access.
  5. Remove the test location and confirm rollback.

This needs read_markets/write_markets and the relevant company scopes. I would not use real professional accounts until that reversible test passes. Please do not post tokens, licence details or customer data here.

If useful, I can turn those steps into a one-page pass/fail checklist, but the actual mutation still needs to be run by someone with authorized access to the store.

9

On the marketUpdate route, the first thing I would test on a dev store is whether conditions.companyLocationsCondition.companyLocationIds replaces the whole list or adds to it. If it replaces, the endpoint has to read current membership, add the approved location, and write the full list back, and two approvals landing at the same moment will quietly drop one.

I would also make the membership check after the write a hard failure rather than a log line, so a wrong catalog shows up at approval time instead of on the first wrong order.

Whatever the test says, I would keep the existing access app as source of truth until the pilot has been through a downgrade as well as an approval, since that is the direction these usually break. :slight_smile:

10

One correction to my earlier test note after checking the current 2026-07 Admin API docs: market condition changes are modelled as conditionsToAdd / conditionsToDelete, and the company-location condition accepts a list of companyLocationIds. So I would not assume the integration has to rewrite the whole membership list until the Grow dev-store test shows the actual behaviour.

A useful minimum test matrix would be:

  1. Add test location A; read the conditions back and verify A receives the expected catalog.
  2. Add test location B while A remains; read back and confirm both are still present.
  3. Delete/downgrade A; confirm A loses access while B remains unaffected.

After each mutation, capture userErrors and query the market conditions again. Any mismatch should block the approval instead of only creating a log entry. That covers the concurrency and downgrade risks Adam raised.

The remaining unknown is still whether the mutation is authorized on a Grow store, so I would keep the current access app as the source of truth until all three tests pass.

Current API references:

11

You are right to separate what the schema permits from what has been proven on a Grow store. My earlier reply was based on Shopify’s current Admin GraphQL schema and plan documentation, not a completed Grow-store test, so I cannot honestly claim this exact mutation has been verified on Grow.

The documentation does establish two useful pieces. MarketConditionsCompanyLocationsInput exposes companyLocationIds, and marketUpdate accepts conditions with conditionsToAdd and conditionsToDelete. Shopify’s plan documentation also says Grow supports B2B markets, with up to three active catalogs across them. The remaining caveat is that schema availability alone does not prove the operation will pass the shop’s runtime capability check.

I would test it as a reversible experiment:

  1. Create one test company location and one draft test market, then use a custom app with the required company and read_markets / write_markets scopes.
  2. Call marketUpdate with the test location under conditions.conditionsToAdd.companyLocationsCondition.companyLocationIds, while requesting both userErrors and the updated company-location condition in the response.
  3. Query the market again to verify the location is present, then remove the same location with conditionsToDelete and verify the rollback.

Keep the API version and any userErrors from that test. If Shopify returns a capability error, the request ID plus the exact mutation gives Support a much narrower question than whether Flow has a native action.

So the accurate answer today is: the documented API shape supports the approach, and Grow supports the relevant B2B-market model, but I have not personally verified that mutation on a Grow production shop. I would treat it as a promising small test, not yet as an established workaround.

12

On the remaining unknown, whether Grow authorises the mutation, you can get most of the answer without running a mutation at all. Query shop { entitlements { markets { b2b { enabled catalogs { enabled limit } } } } } on the Grow store. That is the same entitlement the API checks at runtime, and the 2026-07 schema has explicit error codes when it fails (B2B_CATALOG_LIMIT_REACHED, CANNOT_ACTIVATE_MARKET_B2B_CATALOG_LIMIT_REACHED, UNPERMITTED_ENTITLEMENTS_DIRECT_CATALOG_ASSIGNMENT), so if the test matrix in the last two posts fails you will get a named reason rather than a generic error. Direct catalog-to-company-location assignment is the one that is plan gated, which is why the Markets route is the right one on Grow rather than a workaround.

On the integration itself, you may not need the custom endpoint. Flow has a native Send Admin API request action that runs mutations directly, so it can call marketUpdate with conditionsToAdd when your approval tag is set, with no token stored anywhere. It runs mutations only, so if you need to look up the market ID first use a Get data step.

On restricting products rather than prices: each tier catalog should be publication-only. catalogCreate with the market in context and no price list, then publicationCreate for that catalog, then publicationUpdate to add the allowed products, up to 50 per call. Scopes are read_markets, write_markets, write_products and write_publications.

Agreed that staff app permissions are still all-or-nothing per app. Nothing native solves that yet.

13

@divinebeautysupplies The risky part here is whether the wrong market/catalog assignment can translate into the wrong products being exposed to a customer.

If you have one product URL that should be available only to a specific market, I can run the customer-market path through Drishq MarketCheck and report what Shopify actually exposes for that country context.

No install needed.