Learning PathModule

Associate provisioning patterns

Recommend an associate onboarding pattern that fits a buyer's scale, compliance posture, and self-service needs.

Ask about this Page
Copy for LLM
View as Markdown

After completing this page, you should be able to:

  • Describe four associate provisioning patterns and how each works.

  • Compare the patterns across scale, compliance, effort, and self-service maturity.

  • Recommend a provisioning pattern for a given buyer organization.

Knowing how provisioning works (create Customer, add Associate, assign roles) is only half the job. The harder architectural question is which onboarding pattern fits a given client. The answer depends on the buyer's scale, compliance posture, how much implementation effort is justified, and how much self-service the buyer expects.

This page describes four patterns, from fully seller-controlled to fully automated, and gives a decision matrix for choosing between them.

Pattern A: Seller-managed

The Seller's operations team provisions every Customer and Associate, through the general endpoints or the Merchant Center. Buyers have no self-service: to add or remove a team member, the buyer asks the Seller, who makes the change.
  • Best for: enterprise and regulated industries where onboarding must be tightly controlled and auditable.
  • Effort: low to build, higher to operate, because every change is a manual Seller task.
  • Self-service: none.

Pattern B: Admin-first

The Seller seeds one administrator Associate per Business Unit. That administrator then uses the buyer portal to invite and remove their own team members, without further Seller involvement.

For this to work, the administrator's role needs the UpdateAssociates permission, and any role the administrator may assign must have buyerAssignable: true. The administrator manages members through the as-associate (or me Business Unit) endpoints.
  • Best for: mid-market buyers and portal-first models where the buyer wants to manage its own users.
  • Effort: moderate; the portal must expose member management.
  • Self-service: delegated to a buyer administrator.

Pattern C: Self-register and seller activation

The buyer self-registers: the portal creates a Customer (POST /customers) and a Business Unit (POST /me/business-units). When the Project's My Business Unit creation status is configured to Inactive (which requires explicit configuration in Project Settings), the Business Unit starts inactive, so it cannot yet be used in carts or orders. The Seller verifies the new buyer, then activates the Business Unit, often swapping a default Store for a buyer-specific Store as part of activation.
The Inactive status is the control point: the Project configuration lets a buyer register without immediately gaining the ability to transact, giving the Seller a verification gate.
  • Best for: SMB and digital-first buyers where low-friction sign-up matters but the Seller still wants a verification step.
  • Effort: moderate; needs a self-registration flow and an activation workflow.
  • Self-service: buyer initiates; Seller approves.

Pattern D: SSO and auto-provisioning

The buyer's identity provider (IdP) owns identity. When a user logs in through SSO, a backend-for-frontend (BFF) creates the Customer and Associate records on first sign-in and maps IdP groups to Associate Roles. The IdP remains the source of truth for who exists; commercetools holds the Business Unit and Associate state.

This is an integration pattern, not a built-in platform feature: the mapping from IdP groups to roles lives in your BFF. It suits organizations that already run an enterprise IdP such as Entra ID or Okta and have many users.

A common variant uses a CRM or external system of record as the trigger instead of an interactive login. When the CRM onboards a new buyer organization and its users, it emits an event that an integration consumes to create the matching Business Unit, Customer, and Associate records. The same principle holds: an external system owns onboarding, and integration logic decides which accounts and users sync into commercetools.

  • Best for: large enterprises with an established IdP and high user counts.
  • Effort: highest; requires IdP integration and a provisioning BFF.
  • Self-service: fully automated through the IdP.

Decision matrix

Use these dimensions to choose a pattern.

PatternScaleCompliance postureImplementation effortBuyer self-service
A: Seller-managedSmallStrict, fully controlledLowNone
B: Admin-firstMid-marketModerateModerateDelegated to buyer admin
C: Self-register + activationSMB, many small buyersVerification gate neededModerateBuyer initiates, Seller approves
D: SSO + auto-provisioningLarge enterpriseIdP-governedHighFully automated

Worked example: a pattern for each Zen Electron Trade buyer

Match each buyer to the pattern that fits its profile.

  • Horizon Hotels is a small, flat organization with a handful of procurement staff. The overhead of seller-managed onboarding is acceptable at this size, and there is no need for buyer self-service. Recommend Pattern A (Seller-managed).
  • Pacific Property Group has two Divisions that want to manage their own buyers without calling the Seller each time. Seeding an administrator per Division and letting them invite members fits well. Recommend Pattern B (Admin-first), with the administrator role granted UpdateAssociates and buyer roles set buyerAssignable: true.
  • Atlas Corporate Solutions is a multi-region enterprise with an existing corporate IdP and many users across APAC and EU. Manual onboarding does not scale, and the IdP should remain the source of truth. Recommend Pattern D (SSO + auto-provisioning), with a BFF mapping IdP groups to Associate Roles.

The progression across the three buyers mirrors the complexity spectrum introduced in Module 1: the simplest organization uses the most manual pattern, and the most complex uses the most automated.

Key takeaways

  • Choosing a provisioning pattern is an architectural decision driven by scale, compliance, effort, and self-service needs.
  • Seller-managed (A) keeps all onboarding with the Seller and suits small or tightly controlled buyers.
  • Admin-first (B) delegates member management to a buyer administrator, who needs UpdateAssociates and buyerAssignable roles.
  • Self-register and activation (C) lets buyers sign up into a Business Unit that starts Inactive when the Project is configured that way, giving the Seller a verification gate before activation.
  • SSO and auto-provisioning (D) is an integration pattern where an IdP owns identity and a BFF maps groups to roles; it suits large enterprises.

Test your knowledge