Setting up sales reps in Shopify: native, app, or external?
Access, Interface, and Accountability
The question of how to set up sales reps in Shopify is usually understood as a click-by-click guide. Operationally, though, it's a question about a workplace: which interface does the sales team sit in all day, and which system ends up creating the order?
Anyone working in field sales who navigates the Shopify admin during a customer meeting is sitting in a tool built for people who run a store. And anyone who gets a backend account as an external agent, purely so they can submit orders, formally holds access to a system that has nothing to do with that role, legally or organizationally.
In this article I'll work through the three possible routes, what each does to cost, security, and employees' everyday working life, and how to tell which one fits the setup you already have.
What Comes Before the Decision: One Account for Everyone
Before there are three routes, there is usually no route at all. The sales team doesn't get its own account; it borrows an existing one, the owner's, or a general "office" login whose password gets passed around the team. Orders keep coming in by phone and email, and someone in inside sales types them up afterwards.
It works, which is why it often stays that way for years. It only becomes visible at one specific point: the first question that tries to tie an order to a person.
Because there isn't one on the record. A draft order created through a shared account has no author, only a timestamp. Commissions then get reconstructed from calendar entries, email threads, notes, and memory. Manual price overrides can't be attributed to anyone. And whoever leaves the company still knows a working password.
This is both a security topic and an accounting topic. The cost doesn't only appear at the moment of access; it also appears every time someone has to establish after the fact who did what.
Takeaway: "A shared account saves you the decision, not the work. It just moves the work into reconstruction."
The three routes that follow differ considerably in cost, effort, and comfort. In one respect they don't differ at all: each of them produces an unambiguous link between an order and a person. A shared account fundamentally cannot.
The Precondition: Do You Have Staff Accounts at All?
Before permissions or interfaces come into it, one number decides which routes are even open: how many staff accounts your plan includes.
| Plan | Staff accounts |
|---|---|
| Starter | 0 |
| Basic | 0 |
| Grow | 5 |
| Advanced | 15 |
| Plus | unlimited |
For the native route, that is the actual hurdle — not B2B features in general. The B2B features, meaning companies and company locations, are now available on Basic, Grow, Advanced, and Plus, and sales staff permissions work across all plans too. Plus differentiates elsewhere: unlimited B2B catalogs and the ability to assign a catalog directly to an individual company, where the other plans are capped at three active catalogs across all B2B markets.
In practice that means: on Basic the native route is closed, even though B2B itself is usable. There simply is no account for the sales team to work in. From Grow upward it's open, as long as the team fits the tier. A twelve-person field team on Grow is not a native scenario, however well the features would otherwise suit.
The Native Route: the Shopify Admin as a Workplace
The route Shopify designed works without additional apps or fees and consists of four steps:
- Create the permission set (a "sales" role)
- Create the account
- Send the invitation
- Assign company locations (optional)
Permissions can be defined as templates for multiple accounts, which noticeably reduces the effort when there's turnover in the team. A sales rep typically needs to create draft or real orders and view their assigned customers and products. Access to reports, or editing themes and products, is not required in most cases.
Shopify distinguishes two roles here. Sales managers control which reps work with which company locations, and can additionally take on store administration. Sales representatives only reach the locations and records assigned to them. The minimum combination consists of View companies, Assign staff to company locations, and Restrict permissions to assigned company locations. Up to ten reps can be assigned per company location, and one person can cover any number of locations.
One point regularly surprises people in practice: the restriction to assigned locations filters the Customers, Orders, Draft orders, and Companies pages. Every other page in the Shopify admin does not filter by company. So granting access to analytics or products grants it in full, not narrowed to the rep's own customer base. That doesn't have to be wrong, but it should be known when the role is defined.
The native route has one advantage that's easy to overlook because it's invisible: there is no second system that has to be brought along when Shopify changes, and the behavior is documented. Checkout customizations such as delivery terms are respected on draft orders.
Its disadvantage is the workplace itself. The Shopify admin is an administrative interface, not a sales tool, and for external agents an admin account remains an admin account, however minimal the permissions.
Takeaway: "When the plan provides enough accounts and the team is internal, native is the best answer — both for the features and because it keeps itself current when Shopify ships updates."
The App Route: a Different Interface, the Same Order
The second route depends on the individual app, but the patterns recur. Reps need an identity, either as a staff account in the admin or as a customer account in the store. That identity is selected and flagged inside the app, after which permissions or specific companies, customer accounts, and tags are assigned.
One important difference is the kind of identity. Solutions that work with a customer account instead of a staff account bypass the plan's account limit entirely and grant no admin access. The sales team then orders through the familiar storefront on behalf of the respective customer account. For businesses working with external agents, that is particularly relevant.
The price for it is an additional dependency. The app's permission logic sits on top of Shopify's and has to be understood and audited as well. When Shopify changes, your own timeline hangs on the vendor's. The order is still created in Shopify, though, so Shopify remains the system of record.
Takeaway: "The app route solves an interface problem and a cost problem on plans below Plus. If you have neither, you don't need this approach."
The External Route: Shopify as Destination, Not Workplace
On the third route, the sales team works entirely outside Shopify, in a dedicated portal or an upstream application. The order is captured there and transmitted to Shopify over an interface; in some designs the external system takes over checkout as well. Shopify then stops being the place where the order is created and becomes the system it lands in.
That brings full control over the capture process, bypasses both the account limit and admin access, and makes offline capability possible, which matters in field sales.
In exchange, prices, inventory, customers, and catalogs all have to be kept in sync, and two systems can drift apart. Interface outages become an operational concern of their own. It gets most uncomfortable when customers see both sides: a gap between the price in the portal and the price in the shop is hard to explain and damages trust in both systems.
Takeaway: "The external route is the right answer to a different process, not to individual missing features."
The Special Case Affecting All Three: Draft Orders
As soon as orders are created manually as drafts, one rule holds: anything that happens in the storefront does not happen here. Automatic bundles, discount logic in the theme, tag-based display or pricing rules, storefront scripts. Draft orders in the admin are, after all, created without the storefront running at all.
Server-side logic via Shopify Functions, by contrast, can apply. That can't be reliably predicted across the board, because this area sees regular updates and new bugs. The problem here is primarily that every rule has to be tested individually. For employees who have to name a number in a customer meeting, it makes their job harder.
Anyone who built their pricing logic in the storefront and has reps working through draft orders is running two pricing systems, with all the effort that entails.
Takeaway: "Draft orders work well as long as they don't have to execute storefront rules."
The Solution: Native for as Long as Native Is Possible
My recommendation is deliberately unspectacular, and it follows an order.
- Native, when the plan provides enough accounts, the team is internal, and the sales team is willing to work in the admin. No recurring cost, no additional dependency, documented behavior.
- An app, as soon as one of those conditions breaks. Too many reps for the plan, external agents without admin access, or a sales team for whom the Shopify admin is simply the wrong tool. The question then is which of the three conditions broke, because that determines what to look for.
- An external system, when order capture needs a fundamentally different process rather than just a different interface.
And in all three cases: pricing logic belongs somewhere both routes can see it. Otherwise every decision about where the sales team works gets reopened later by the pricing question.
Comparison of the Three Routes
| Aspect | Native | With app | External | Shared account |
|---|---|---|---|---|
| Workplace | Shopify admin, an administrative interface | Embedded or storefront interface | Dedicated portal | Varies, usually the admin |
| Account required | Staff account, only from Grow (5), Advanced 15, Plus unlimited | Staff or customer account, the latter without a plan limit | None in Shopify | One account for several people |
| External agents | Requires admin access, delicate | Possible without admin access | Possible without admin access | Not traceable |
| Customer assignment | Company locations, up to 10 reps per location | App-dependent, often via tags or rules | In the external system | None |
| Restricting visibility | Only on four page types | App-dependent | Platform dependent | Not at all |
| Storefront pricing logic | Doesn't apply to draft orders, only Shopify Functions | Applies when ordering through the shop; on drafts, as native | Has to be kept in sync | As native |
| Offline capability | No | App-dependent | Usually possible | No |
| Recurring cost | None, only the plan tier | App fee | Fee, possibly an interface | None visible |
| When Shopify changes | Shopify brings it along | Timeline hangs on the vendor | Your own adaptation effort | Goes unnoticed |
| On outage | No additional point of failure | App unreachable, Shopify unaffected | Orders drift apart | / |
| Traceability | Clean per account | Clean per person | Clean in the external system | Not given; the password stays known after someone leaves |
| A good fit when | the plan provides enough accounts, the team is internal and willing to work in the admin | the account limit, external partners, or the interface is the problem | capture needs a process of its own | never, except as a deliberate interim step |
Outlook
This article has looked at setup from a high altitude. In the further articles in this series I'll go into the individual pieces: permissions in detail, assigning customers to reps, and what staff accounts in Shopify actually cost — in fees, in access, and in risk.