Learning PathModule

Decision framework: org modeling

Apply the Native, Configurable, Modeling strategy lens to org management and access control, and recognize where integration begins.

Ask about this Page
Copy for LLM
View as Markdown

After completing this page, you should be able to:

  • Apply the Architect's decision framework to access-control requirements.

  • Explain the handoff between identity provider authentication and Associate authorization.

  • Identify which org-modeling requirements are native and which cross an integration boundary.

This page consolidates Modules 1 and 2 into a single, repeatable way to evaluate a B2B org-modeling requirement. It reuses the Architect's decision framework from Module 1: a learning aid for this path, not official commercetools guidance, that helps you reason about how to meet a requirement with the platform.

Recap: the three-layer lens

For any requirement, ask three questions in turn.

LayerQuestion
NativeWhat does commercetools handle out of the box?
ConfigurableWhat can be configured or extended within commercetools?
Modeling strategyHow can you model this requirement using commercetools resources and patterns?

Applied to access control, the layers map cleanly onto the resources from this module.

LayerApplied to "who can do what inside the buyer organization"
NativeAssociates, Associate Roles, and the permission catalog define who can act and what they can do; the Permission Gate enforces it on as-associate calls.
ConfigurableCustom roles, the buyerAssignable flag, and associateMode / inheritance settings shape access per Business Unit and across the hierarchy.
Modeling strategyCompose roles, inheritance, and a provisioning pattern to match the organization's structure and governance, separating requester and approver roles for separation of duties.

The authentication and authorization handoff

A frequent point of confusion is the boundary between authentication and authorization. They are different responsibilities, often owned by different systems.

  • Authentication answers who is this user? In an enterprise B2B setup, this is typically owned by the buyer's identity provider (IdP).
  • Authorization answers what may this user do for this company? This is owned by commercetools through the Associate's roles and the permissions they grant.

The handoff is clean: your IdP authenticates the user, and the Associate's permissions authorize their actions within the Business Unit context. The SSO and auto-provisioning pattern from the previous page is exactly this handoff implemented in a backend-for-frontend, where IdP groups are mapped to Associate Roles.

Where integration begins

The framework is designed to cover the majority of B2B implementations using native capabilities. It is still useful to recognize the points where org modeling reaches beyond the platform and into integration, so you can set realistic expectations:

  • Buyer onboarding automation beyond the built-in provisioning patterns, for example syncing buyer organizations from an external system of record.
  • SSO and IdP integration, where the IdP owns identity and a BFF provisions Associates.
  • Punchout catalogs (cXML or OCI), where the buyer's procurement system drives the shopping session.

These are touchpoints to flag, not gaps to dwell on. As in Module 1, the customer-specific business logic these touchpoints imply lives in an orchestration or middle layer on top of the native resources. The goal is to know which requirements you meet natively and which need an integration, so your architecture is honest about both.

Worked example: Zen Electron Trade access-control architecture

Bring Modules 1 and 2 together for all three buyers, mapping each requirement to the layer that meets it.

  • Horizon Hotels: a flat Company with a small team. Native Associates and a buyer role plus an administrator role cover access. Modeling strategy: seller-managed provisioning (Pattern A). No integration boundary is crossed.
  • Pacific Property Group: a Company with two Divisions, buying and approving separated. Native roles plus configurable associateMode and inheritance let a company administrator manage both Divisions while buyers stay local. Modeling strategy: admin-first provisioning (Pattern B) with separated requester and approver roles, ready for Approval Rules in Module 7.
  • Atlas Corporate Solutions: a multi-region enterprise with an existing IdP. Native Associates and roles still authorize actions, but authentication is owned by the IdP. Modeling strategy: SSO and auto-provisioning (Pattern D), which crosses an integration boundary: the IdP-to-role mapping lives in a BFF, outside the platform.

Across the three, the native resources are the same; what changes is the configuration and the provisioning pattern, and only the largest buyer crosses an integration boundary. That is the framework working as intended: cover the common case natively, and name the boundary when you reach it.

Key takeaways

  • The Native / Configurable / Modeling strategy lens gives a repeatable way to evaluate org-modeling requirements; it is a learning aid, not official guidance.
  • For access control: Associates, roles, and the Permission Gate are native; custom roles, buyerAssignable, and inheritance settings are configurable; composing them into a governance model is the modeling strategy.
  • Authentication (who the user is) is often owned by an IdP; authorization (what they may do) is owned by commercetools through Associate permissions.
  • Integration boundaries in org modeling include external onboarding automation, SSO/IdP integration, and punchout catalogs.
  • Most B2B access-control needs are met natively; name the integration boundary only when a requirement genuinely reaches beyond the platform.

Test your knowledge