Stitchflow
BigCommerce logo

BigCommerce User Management Guide

Manual workflow

How to add, remove, and manage users with operational caveats that matter in production.

UpdatedMar 4, 2026

Summary and recommendation

BigCommerce user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.

BigCommerce user management lives under Store Control Panel → Account Settings → Users. Three account types exist: Store Owner (one per store, unrestricted, non-demotable), Staff Users (permission-set-based, counted against plan seat limits), and API Accounts (OAuth credentials only, no control panel login, not counted against seat limits).

Every app your team uses for store operations is gated through these three types, so mapping roles before provisioning saves rework.

Quick facts

Admin console pathStore Control Panel → Account Settings → Users
Admin console URLOfficial docs
SCIM availableNo
SCIM tier requiredEnterprise
SSO prerequisiteNo

User types and roles

Role Permissions Cannot do Plan required Seat cost Watch out for
Store Owner Full, unrestricted access to all control panel areas including billing, plan changes, and user management. Cannot be restricted. Cannot be demoted to a staff role; only one store owner per store. All plans Included in plan; not a separately billed seat. Store ownership can only be transferred by contacting BigCommerce support; it cannot be reassigned from within the control panel.
Staff User (predefined role) Access determined by assigned permission set. Available permission sets include: Store Administrator (near-full access), Manage Orders, Manage Products, Manage Customers, Manage Marketing, View Reports, and others. Each set grants access to specific control panel sections. Cannot access billing or plan management. Cannot create or manage other users unless granted Store Administrator permissions. Standard plan and above; number of staff users varies by plan (Standard: 5, Plus: 5, Pro: 8, Enterprise: unlimited). Included within plan user-count limits; no per-seat add-on pricing published for standard plans. User count limits are enforced per plan tier. Exceeding the limit requires a plan upgrade. The Standard plan allows up to 5 staff users.
API Account (Store API Account) OAuth scopes selected at creation time. Scopes are granular (e.g., read-only or read/write for Orders, Products, Customers, etc.). Used for integrations, not human login. Cannot log into the control panel UI. Not a human user account. All plans Does not consume a staff user seat. Client secret is shown only once at creation; it cannot be retrieved afterward. Losing it requires generating a new API account.

Permission model

  • Model type: role-based
  • Description: BigCommerce uses predefined permission sets assigned to staff users. Each permission set maps to a collection of control panel sections and actions. There is no fully custom role builder in the standard UI; administrators select from a fixed list of permission sets per user. Enterprise plans may have additional configuration options via account management.
  • Custom roles: No
  • Custom roles plan: Not documented
  • Granularity: Section-level within the control panel (e.g., Orders, Products, Customers, Marketing, Reports). Not field-level or record-level granularity.

How to add users

  1. Log in to the BigCommerce control panel as Store Owner or a user with Store Administrator permissions.
  2. Navigate to Account Settings → Users.
  3. Click 'Create a User Account'.
  4. Enter the user's email address.
  5. Select a permission set from the available predefined options.
  6. Click 'Save'.
  7. BigCommerce sends an invitation email to the specified address. The user must accept the invitation and set a password to activate the account.

Required fields: Email address, Permission set selection

Watch out for:

  • The invited user must have or create a BigCommerce account tied to that email address.
  • If the store has reached its plan's user limit, the 'Create a User Account' option will be unavailable until the plan is upgraded.
  • Invitation emails can go to spam; users should check junk folders.
  • There is no way to set a password on behalf of the user; they must complete the invitation flow themselves.
Bulk option Availability Notes
CSV import No Not documented
Domain whitelisting No Automatic domain-based user add
IdP provisioning Yes Enterprise (via third-party IdP integrations such as Okta, OneLogin, or miniOrange; no native SCIM provisioning)

How to remove or deactivate users

  • Can delete users: Yes
  • Delete/deactivate behavior: Staff user accounts can be deleted from Account Settings → Users. BigCommerce also supports disabling (deactivating) a user without full deletion by unchecking the 'Active' status on the user record, which prevents login while retaining the account.
  1. Navigate to Account Settings → Users in the control panel.
  2. Locate the user in the list.
  3. Click the user's name or the edit icon.
  4. Uncheck the 'Active' checkbox to deactivate, or click 'Delete' to permanently remove the account.
  5. Save changes.
Data impact Behavior
Owned records Orders, products, and other records created by the staff user remain in the store and are not deleted when the user is removed.
Shared content Content such as product listings, order notes, and customer records created by the user persist and remain accessible to other staff.
Integrations API accounts are separate from staff user accounts; deleting a staff user does not revoke associated API credentials. API accounts must be deleted separately.
License freed Deleting or deactivating a staff user frees up one seat against the plan's user limit, allowing a new user to be added without a plan upgrade.

Watch out for:

  • Deactivating a user (setting to inactive) prevents login but the account still counts against the plan's user seat limit according to some user reports; deletion is required to free the seat.
  • The store owner account cannot be deleted or deactivated from within the control panel.
  • There is no bulk delete option for staff users; each must be removed individually.

License and seat management

Seat type Includes Cost
Staff User Seat Access to the BigCommerce control panel with assigned permission set. Counts against plan user limit. Included in plan subscription; no published per-seat add-on price for Standard/Plus/Pro tiers.
API Account OAuth credentials for API access. Does not grant control panel login. Not counted against staff user seat limit. Included in all plans at no additional charge.
  • Where to check usage: Account Settings → Users (displays current user count and plan limit)
  • How to identify unused seats: No built-in last-login reporting is surfaced in the standard control panel UI. Administrators must manually review the user list or use API audit logs if available on their plan.
  • Billing notes: Staff user limits are enforced by plan tier: Standard (5 users), Plus (5 users), Pro (8 users), Enterprise (unlimited). Exceeding the limit requires a plan upgrade. Billing is per store subscription, not per seat.

The cost of manual management

Staff user seat limits are enforced by plan tier: Standard and Plus plans cap at 5 users, Pro at 8, and Enterprise is unlimited. Exceeding the limit blocks the 'Create a User Account' action entirely until the plan is upgraded.

There is no published per-seat add-on price for Standard, Plus, or Pro tiers - the only path past the cap is a plan upgrade. API Accounts are included at no additional charge on all plans.

What IT admins are saying

The most consistent friction reported by BigCommerce administrators centers on three gaps. First, there is no native automated provisioning - every app that needs user lifecycle management requires a third-party connector (miniOrange, LoginRadius, or Okta's custom app).

Second, permission sets are predefined and not fully customizable, so teams with specialized roles must accept the closest available set or escalate to Enterprise account management.

Third, there is no built-in last-login or activity reporting in the standard control panel, making inactive account cleanup a manual, list-by-list process. Store ownership transfers require contacting BigCommerce support directly - there is no self-service path.

Common complaints:

  • No native SCIM support; third-party tools (miniOrange, LoginRadius, Okta) are required for automated provisioning/deprovisioning.
  • Permission sets are predefined and not fully customizable, limiting granular access control for specialized staff roles.
  • Staff user seat limits on lower-tier plans (Standard: 5, Plus: 5) are considered restrictive for growing teams.
  • No built-in last-login or user activity reporting makes it difficult to identify inactive accounts for cleanup.
  • Transferring store ownership requires contacting BigCommerce support rather than a self-service control panel action.
  • Invitation-based onboarding means admins cannot set passwords on behalf of users, creating friction for onboarding.
  • Okta SCIM integration requires Enterprise plan and third-party configuration, adding complexity and cost.

The decision

Choose deletion over deactivation when a staff member departs: deactivated accounts may still count against the plan's seat limit per user reports, and there is no bulk removal tool - each account must be deleted individually.

For onboarding, admins cannot set passwords on behalf of users; the invited user must complete the email invitation flow themselves, which adds a dependency step.

If your team is approaching the plan's user cap, audit the user list proactively - the control panel shows current count versus plan limit at Account Settings → Users, but provides no last-login signal to identify candidates for removal.

Bottom line

BigCommerce's manual user management is straightforward for small teams but shows friction at scale: fixed permission sets limit granular access control, seat caps on lower tiers force plan upgrades rather than seat-level purchases, and the absence of last-login data makes access hygiene reactive rather than proactive.

Every app integration requiring automated provisioning or deprovisioning will need a third-party connector, as there is no native SCIM endpoint.

Teams that stay within their plan's seat limit and can tolerate predefined roles will find the control panel adequate; teams with compliance requirements around access reviews or frequent staff turnover will hit these gaps quickly.

Automate BigCommerce workflows without one-off scripts

Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.

Every app coverage, including apps without APIs
60+ app integrations plus browser automation for apps without APIs
IT graph reconciliation across apps and your IdP
Less than a week to launch, maintained as APIs and admin consoles change
SOC 2 Type II. ~2 hours of your team's time

UpdatedMar 4, 2026

* Details sourced from official product documentation and admin references.

Keep exploring

Related apps

Abnormal Security logo

Abnormal Security

API Only
AutomationAPI only
Last updatedMar 2026

Abnormal Security is an enterprise email security platform focused on detecting and investigating threats such as phishing, account takeover (ATO), and vendor email compromise. It does not support SCIM provisioning, which means every app in your stack

ActiveCampaign logo

ActiveCampaign

API Only
AutomationAPI only
Last updatedFeb 2026

ActiveCampaign uses a group-based permission model: every user belongs to exactly one group, and all feature-area access (Contacts, Campaigns, Automations, Deals, Reports, Templates) is configured at the group level, not per individual. The default Adm

ADP logo

ADP

API Only
AutomationAPI only
Last updatedFeb 2026

ADP Workforce Now is a mid-market to enterprise HCM platform that serves as the HR source of record for employee data — payroll, benefits, time, and talent. User access is governed by a hybrid permission model: predefined security roles (Security Maste