User and Rights Management in SAP Commerce: Groups, Inheritance, and the Deny Trap

Business-user access is the part of a SAP Commerce project most reliably postponed to the end, and most reliably regretted. The team pours months into the storefront and customer experience, then throws together Backoffice permissions during application management, when the people setting them up lack the knowledge to do it structurally. The result is a messy, contradictory permission model that business users fight daily and that becomes nearly impossible to untangle once production data depends on it. This guide is the model done right: the group and inheritance mechanics, the standard groups, the permission-conflict rules, and the one discipline (avoid denies by default) that keeps the whole thing manageable. Design it early, alongside the storefront, not after.

Groups and Inheritance: The Whole Foundation#

Access in SAP Commerce is granted through user groups, and two properties make them powerful:

• A user can belong to multiple groups.
• Groups can nest, and access rights inherit down the hierarchy.

So a user in productmanagergroup gets permissions from three sources: any direct grants on the user (avoid these, below), grants on their direct group, and inherited grants from parent groups (for example employeegroup). The group hierarchy is the permission model, and designing it well is most of the job.

The recommended-practice hierarchy for a real organization (a global company with multiple sites and sales organizations) encodes several rules worth stating as law:

• Never grant permissions to individual users. It does not scale, and it is the first thing that makes a model unmanageable. Everything goes through groups.
• Reuse out-of-the-box roles as the starting point of the hierarchy rather than building from scratch.
• Inherit the cockpit group so employee groups get cockpit functionality across all cockpits.
• Assign access rights high in the tree so they cascade, but assign catalog read/write and language permissions lower and per-market, because that is where users differ (a German-catalog editor versus a French-catalog editor should differ in catalog rights while sharing everything else). This separation lets people have different content responsibilities without duplicating the access-rights scaffolding.
• Reader and manager group pairs are the idiomatic way to grant read-only versus read-write.
• Only grant write on Staged catalog versions, never on Online, so nobody accidentally edits the live version (the content catalog guide's staged-to-online model).
• Grant synchronization permissions explicitly to a specific group, because publishing to the live world is a privilege, not a default.
• Do not grant language permissions high in the tree, or every user below inherits every language; scope them where they belong.

The through-line: structure the hierarchy so shared things live high and differentiated things (catalog, language, sync) live low and per-market. That single shape is what keeps a hundred-user Backoffice manageable.

The Standard Groups#

SAP Commerce ships groups that anchor the model:

• admingroup: created at system setup, cannot be removed, unrestricted, with Administration Console access and the power to change the system drastically. Never give it to business users. It is for technical administrators only. Handing admingroup to a merchandiser to "make the permission error go away" is the most common and most dangerous access shortcut.
• employeegroup: not mandatory but used by all standard modules, so it is the recommended root for all employee groups. Your hierarchy hangs off this.
• cockpitgroup: the root type cockpits use to show groups and users in query dialogs; employee groups should inherit from it for full cockpit access.

Start from these, build your organization-specific groups beneath employeegroup, and reuse the shipped role groups where they fit.

Type and Attribute Permissions#

Access rights define permissions on data items, and the granularity goes deep:

• Permissions apply at the type level (may this group read/write Product?) and the individual attribute level (may they write Product.price specifically?). Attribute-level control is what lets a pricing team edit prices while a content team edits descriptions on the same type.
• Grant permissions at group level, not user level, so they are shared and manageable.
• Each permission is granted, denied, or neutral (not specified). Neutral falls back to inherited rights from parents, which is the mechanism that makes the hierarchy work: leave most things neutral and let inheritance decide.

These rights are authored in ImpEx user-rights blocks (the ImpEx guide), version-controlled like the code they are, so the permission model is reproducible across environments rather than clicked into one Backoffice and lost.

The Conflict Rule and the Deny Trap#

Because users belong to multiple groups and groups nest, permissions conflict: one group grants read on a type, another denies it. SAP Commerce resolves conflicts with two rules:

1. Closest inheritance level wins: a grant (or deny) on the user's direct group beats an opposite setting on a distant ancestor.
2. At the same level, deny wins: two conflicting settings equally close, and the deny prevails.

This sounds orderly and becomes a nightmare in practice, because conflicting permissions are very hard to diagnose and usually surface in production, when a business user cannot do something they should and tracing why through a multi-group, multi-level hierarchy is genuinely painful. The best-practice corrective is one rule that prevents most of the pain: avoid denies by default. Build the model out of grants and neutrals, granting positively where access is wanted and leaving neutral where it is not, so inheritance and absence-of-grant do the restricting rather than explicit denies that collide unpredictably. Reserve explicit deny for the rare case where you must revoke something inheritance grants, and document it loudly. A model without denies has no conflicts to diagnose; a model peppered with denies is a production incident waiting for the wrong two groups to meet on one user.

Cloud Portal Access Is Separate#

One clean separation to keep in mind: access to the Cloud Portal (the operations plane, the Cloud Portal ops guide) is governed entirely separately from these Backoffice groups. Portal users are managed in the portal, with its own roles deciding who can deploy, back up, and manage environments (the security hardening guide's least-privilege on the operations plane). Do not conflate "can edit products in Backoffice" with "can deploy to production"; they are different systems with different access models, and both need deliberate, least-privilege design.

Do It Early, Stick to the Strategy#

The meta-lesson the source presses, and it is correct: choose a permission strategy early and stick to it. The model is postponed because it feels like application-management work, but it is architecture: it needs the same up-front, structured design as the data model, by people who understand the inheritance mechanics, captured in version-controlled ImpEx. A model designed early is clean; a model accreted in production out of expedient grants and panic denies is the messy area every long-running estate has and nobody enjoys owning.

Checklist#

• Permission model designed early, alongside the storefront, not deferred to application management
• All permissions through groups, never individual users; OOTB roles reused as the base
• Hierarchy rooted at employeegroup, inheriting cockpitgroup; admingroup for technical admins only
• Shared rights high in the tree; catalog, language, and sync rights low and per-market/organization
• Write granted only on Staged versions; synchronization granted explicitly to specific groups
• Type and attribute permissions at group level; most settings neutral, relying on inheritance
• Denies avoided by default; the few that exist documented, to prevent production conflict-diagnosis pain
• Model captured in version-controlled ImpEx user-rights blocks; reproducible across environments
• Cloud Portal access designed separately with its own least-privilege roles

Rights management is invisible when it works and agonizing when it does not, and which one you get is decided by whether you designed it as architecture early or assembled it as expedient patches late. Structure the hierarchy, grant through groups, avoid denies, version the ImpEx, and the business users who live in Backoffice will never think about permissions, which is exactly the goal.