Give company-store operators access to the tasks they perform, not a blanket administrator login. Separate product editing, order support, financial changes and user management; then test both what each role can do and what it must not do. The practical decision is not how many people deserve to be called administrators. It is which actions each person needs, on which stores and records, for how long.
A marketing coordinator may need to replace a product photo without seeing every employee’s delivery address. A support specialist may need to investigate a shipment without changing payment settings. A finance reviewer may need a reconciliation report without publishing merchandise. Treating all three as the same role makes a simple store harder to govern.
Publisher perspective: Brand Sauce publishes this operational framework for company-store buyers. The suggested roles and tests are requirements to discuss with your provider, not a claim that Brand Sauce or any platform supports every control described here. Official references were reviewed October 22, 2026; implementation scope and pricing are quote-needed.
Start with actions and records, not job titles
Write down the recurring work before opening the permissions screen. “Marketing access” is too vague. “Edit descriptions and submit new artwork for approval in the employee store” is a usable requirement. Add whether the person may publish changes directly, change prices or create a new product.
Use four fields for every requirement: person or role, permitted action, record scope and duration. For example: “Event coordinator; view fulfillment status; orders for the autumn conference only; through the closeout date.” If the platform cannot restrict records to that event, the requirement has exposed a real gap—not a reason to silently grant access to every order.
OWASP’s authorization guidance distinguishes proving identity from deciding what that identity may do. It recommends minimum necessary privileges, default denial and authorization checks on every request. For a buyer, the implication is straightforward: a successful login or a hidden menu item does not establish that access boundaries work.
This guide focuses on back-office operator access. Our employee access and offboarding guide addresses the broader recipient lifecycle. Someone may be allowed to shop without being allowed to administer anything.
Build a task-based role matrix
The following is a starting design, not a universal software configuration. A small team may assign several responsibilities to one person, but it should still understand which powers are being combined.
| Work role | Access to investigate | Keep separate unless specifically needed |
|---|---|---|
| Catalog editor | Approved product descriptions, images and assortment changes | Recipient exports, refunds, payment settings and user administration |
| Order support | Relevant order status and the recipient details needed to resolve a case | Bulk exports, price changes and unrestricted financial adjustments |
| Finance reviewer | Invoices, transaction reports and reconciliation evidence | Product publishing, user invitations and operational order changes |
| Program funding operator | Approved allowance or campaign-funding actions within a defined scope | Changing their own authority or approving their own exceptions |
| Identity administrator | Inviting users, assigning approved roles and removing access | Routine merchandising and financial transactions |
| Technical maintainer | Agreed theme, integration or configuration work | Permanent unrestricted access after the project ends |
Distinguish reading, editing, exporting and deleting. A person who can view a single order may not need a downloadable file containing the whole recipient population. A reviewer who needs totals may be able to work with a narrower report. Ask what data each report and export actually contains.
Also separate product content from commercial authority. Publishing an unapproved price or opening an unavailable item can create an operational problem even if the editor never sees personal data. Identify the exact publishing action and whether a second review is technically enforced or simply part of the team’s procedure.
Check effective access, not just the role name
Shopify’s role documentation provides a useful concrete example: a role groups permissions, a user can hold multiple roles, and those roles grant cumulative permissions. Available role categories and permissions depend on the store’s organizational and subscription context. A predefined role name is therefore not a substitute for reviewing the actual configuration.
For any shortlisted provider, ask for an effective-access demonstration using a representative operator account. List every assigned role, the stores it covers, and any additional access supplied through apps or a provider portal. Do not assume that adding a narrow role reduces privileges already granted by a broader one.
Inspect the exact plan and environment proposed in the quote. A sales demonstration in a different tier does not prove your configuration includes custom roles, restricted exports or separate store scopes. Record unavailable controls as gaps with an agreed alternative; do not label them “included” because the provider can potentially build them.
For managed services, clarify who performs the action. The client may request a change while provider staff execute it. That can be a workable division, but the service process needs an authorized requester, a review rule and a traceable completion record. A request form is not the same thing as a client administrator account.
Make financial and access-changing powers explicit
Shopify’s sensitive-permissions guidance identifies areas such as billing payment methods and other payment settings, and notes that administrator roles can carry sensitive access. It recommends care when assigning those permissions and encourages two-step authentication. Use that as a prompt to examine the actual powers behind broad administrative roles, not as a complete list for every store platform.
In a merchandise program, separately review the ability to issue funded value, change allowances, refund a payment, restore a promotional balance, export recipient data, install an app or invite another administrator. These actions affect different resources. “Can help with orders” should not automatically authorize all of them.
Where a second person must approve a change, confirm where that approval is enforced. A note saying “ask finance first” is an operating instruction, not a technical block. If enforcement is manual, name the reviewer and keep the decision attached to the requested action. Our order-approval queue guide explains the separate question of moving an approved request into production.
For an illustrative small-team arrangement, one operator could prepare a campaign allocation while another checks the recipient count and funding total before release. If the software cannot separate preparation from release, an alternative is a provider-executed change based on a recorded approval. That adds coordination time; compare it honestly with the cost and complexity of implementing a finer-grained workflow.
Use allowed-and-denied tests before handing over accounts
Ask the provider and your technical owner to run these checks in an authorized test environment using synthetic recipients and nonproduction transactions. The goal is to validate agreed boundaries, not to experiment with real employee records or real refunds.
| Test account | Expected allowed action | Expected denied action |
|---|---|---|
| Catalog editor | Update an approved test product description | Export recipient addresses or change payment settings |
| Scoped support operator | Open an assigned test order | Open an order outside the agreed store or program scope |
| Finance reviewer | Read the agreed reconciliation report | Issue a refund or alter a product without separate authority |
| Temporary maintainer | Perform the agreed maintenance task during the access window | Continue that task after access is withdrawn |
| Combined-role user | Perform the intended combined tasks | Gain an unapproved power through an overlooked additional role |
Request evidence beyond screenshots of hidden navigation. The technical owner should verify that disallowed requests are rejected at the authorization boundary, including direct access paths and exports relevant to the implementation. Keep the evidence understandable: account, action, scope, expected result, observed result, date and environment.
Repeat the affected checks after changing roles or adding an app that touches the same data. A successful launch test is evidence about that configuration, not a permanent certification of every future change. If a required boundary fails, narrow the rollout or keep the task with an authorized operator until the gap is resolved.
Cover vacations, vendors and emergency access
A single owner account used for everyone’s work makes it difficult to identify who changed what. Prefer named operator accounts with the organization’s approved authentication setup. Maintain a separate recovery arrangement through the responsible IT owner; do not put recovery material in a shared merchandising spreadsheet.
For temporary cover, specify the tasks, start date, end date and removal owner. If automatic expiry is unavailable, schedule a documented removal check. When someone changes jobs, reassess their old responsibilities rather than only adding the new role.
Vendor and agency access needs the same treatment. Ask whether their access is individually attributable, what store data they can reach, and who removes it when the work ends. An agency’s need to adjust a theme does not by itself explain permanent access to finance or recipient exports.
For exceptional urgent work, define an escalation path before an event deadline arrives. Record the reason for broader access, the approving person, the permitted task and the time it ends. Afterward, verify removal and review the actions performed. A recovery route should keep the store operable without turning an emergency exception into the everyday role.
Match the controls to the operating model
An always-on, individually fulfilled store may need frequent product and order-support work across many small purchases. A bulk event program may involve fewer operators but larger commitments and concentrated recipient files. Neither model removes the need to control financial changes or data access.
Bulk can be appropriate for a known roster, a coordinated distribution date or a production process suited to a batch. A hybrid can combine a controlled event order with later individual selections. Choose permissions around the work each route creates, rather than treating on-demand fulfillment as a security feature or assuming it always wins.
Compare three ways to satisfy a difficult requirement: native platform permissions, a managed-service approval process, or custom implementation. Native controls may be easier to demonstrate but may not match every record boundary. A managed process can reduce client-side privileges while adding turnaround dependencies. Custom work can target a specific gap but needs ownership, maintenance and acceptance testing. Costs and supported capabilities require a scoped quote.
If your team is deciding who should operate the underlying storefront at all, the Shopify versus managed company-store comparison addresses that broader responsibility choice. This permission matrix belongs in either route’s handoff.
Copyable operator-access approval record
- Identity: named operator, employer or provider, and accountable internal sponsor.
- Task: the recurring work or temporary assignment requiring access.
- Actions: view, edit, publish, export, delete, fund, refund or administer users, as applicable.
- Scope: stores, programs, records and fields that may be accessed.
- Effective permissions: all assigned roles and relevant app or portal access.
- Limits: prohibited actions, approval dependencies and known platform gaps.
- Evidence: allowed-and-denied test results for the agreed configuration.
- Lifecycle: start, expiry or review date, removal owner and handoff contact.
Review the record when responsibilities, software or service arrangements change. Ask the operator what work they still perform; remove powers that no longer have a purpose. Keep an approved backup for essential tasks so restricted access does not become a reason to share the owner account.
Company-store administrator permission FAQs
Does single sign-on solve administrator permissions?
No. Sign-in establishes identity through the chosen route. You still need to determine the person’s permitted actions and record scope inside the store and connected tools.
Can one person hold several roles?
Yes, if the combined access is intentional and appropriate. Review the effective permissions together. Two individually reasonable roles may create an unplanned combination of funding, approval or user-management powers.
What if a provider offers only full administrator access?
Do not pretend that a task-specific role exists. Consider keeping administration with a smaller authorized group, using a documented service request process for other staff, or selecting an implementation that supports the required boundaries. Compare the operational tradeoffs before committing.
How do we know the handoff is complete?
Every operator should have an approved task and scope, required work should succeed, prohibited work should be denied, and temporary access should have a removal owner. A list of invited email addresses alone is not an access-control handoff.
