# Associate provisioning patterns

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](/api/associates-overview.md#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.

| Pattern | Scale | Compliance posture | Implementation effort | Buyer self-service |
| --- | --- | --- | --- | --- |
| **A: Seller-managed** | Small | Strict, fully controlled | Low | None |
| **B: Admin-first** | Mid-market | Moderate | Moderate | Delegated to buyer admin |
| **C: Self-register + activation** | SMB, many small buyers | Verification gate needed | Moderate | Buyer initiates, Seller approves |
| **D: SSO + auto-provisioning** | Large enterprise | IdP-governed | High | Fully 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.

## Related pages

- [Area overview page with navigation](/learning-model-b2b-commerce.md)
- [Previous page: API endpoint patterns for B2B](/learning-model-b2b-commerce/configure-associate-access/api-endpoint-patterns-for-b2b.md)
- [Next page: Decision framework: org modeling](/learning-model-b2b-commerce/configure-associate-access/decision-framework-org-modeling.md)