Summary and recommendation
SAP Commerce 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.
SAP Commerce user management splits across two separate consoles.
The Backoffice Administration Cockpit handles application-level users (employees, admins, B2B customers), while the SAP Commerce Cloud Portal (portal.commerce.ondemand.com) governs cloud environment access.
A user needing both must be provisioned independently in each system because there is no unified sync between them.
This dual-console requirement is the single most operationally burdensome aspect of day-to-day administration.
Quick facts
| Admin console path | Backoffice Administration Cockpit (for platform user/role management); SAP Commerce Cloud Portal (https://portal.commerce.ondemand.com) for cloud environment and portal-level user management |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Customer (B2C/B2B Storefront User) | Can browse storefront, place orders, manage own account, view order history. B2B customers may have additional organizational account permissions depending on configuration. | Cannot access Backoffice administration, cannot manage other users unless granted B2B unit-level admin rights. | Customer accounts are managed separately from employee/admin accounts. B2B customer hierarchies (units, user groups) require additional configuration in Backoffice. | ||
| Employee / Backoffice User | Access to Backoffice Administration Cockpit based on assigned user groups and access rights. Can manage catalog, orders, promotions, and other commerce data per granted permissions. | Cannot perform actions outside their assigned user group permissions. Cannot access SAP Commerce Cloud Portal unless separately provisioned. | Employee accounts are of type 'Employee' in the platform type system. Permissions are inherited through user group membership and can be complex to audit. | ||
| Administrator (Backoffice Admin) | Full access to Backoffice Administration Cockpit. Can manage users, user groups, access rights, catalog, orders, and all platform configuration. | Backoffice admin access does not automatically grant SAP Commerce Cloud Portal access; portal access is managed separately. | The default 'admin' superuser account should not be used for day-to-day operations. SAP recommends creating named admin accounts with appropriate group memberships. | ||
| SAP Commerce Cloud Portal User | Access to the SAP Commerce Cloud Portal for managing cloud environments, deployments, builds, and environment-level configurations. Roles include: Customer System Administrator, Customer Developer, Customer Operations. | Portal roles do not grant Backoffice access within the commerce application itself. Portal access is scoped to cloud infrastructure management. | SAP Commerce Cloud (cloud-hosted deployment) | Portal user management is separate from application-level Backoffice user management. Users must be provisioned in both systems independently if access to both is needed. |
Permission model
- Model type: hybrid
- Description: SAP Commerce uses a hybrid permission model combining role-based access (via predefined user groups such as 'admingroup', 'backofficeadmingroup', 'employeegroup') with fine-grained, attribute-level access rights configurable per user group. Permissions are inherited hierarchically through user group membership. The Backoffice Framework adds a separate widget/perspective-level access control layer on top of the platform type-system permissions.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Attribute-level: read/write/create/delete/change permissions can be set per type (object), attribute, and user group. Backoffice adds UI-level widget and perspective visibility controls per user group.
How to add users
- Log in to the Backoffice Administration Cockpit with an account that has user management permissions.
- Navigate to: User > Employees (for internal/admin users) or User > Customers (for storefront customers).
- Click the '+' (Create new item) button.
- Fill in required fields: UID (unique identifier/login), name, and password (or configure SSO).
- Assign the user to one or more User Groups to grant appropriate permissions.
- Save the new user record.
- For SAP Commerce Cloud Portal users: log in to the Cloud Portal (portal.commerce.ondemand.com), navigate to Security > Users, invite the user by email, and assign a portal role.
Required fields: UID (unique login identifier), Name (display name), Password (if not using SSO/LDAP), User Group assignment (for permissions)
Watch out for:
- Backoffice user creation and Cloud Portal user provisioning are two separate processes; a user may need to be added in both places depending on their responsibilities.
- UIDs must be unique across the platform; reusing a UID after deletion may cause conflicts depending on configuration.
- Password policies and complexity requirements are configurable at the platform level and may vary by deployment.
- If LDAP or SSO is configured, user accounts may be auto-provisioned on first login, but group assignments may still need to be configured manually.
- B2B customer user creation requires additional steps to assign users to B2B units and configure organizational roles.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Backoffice > System > Import (ImpEx import tool accepts CSV-based ImpEx scripts for bulk user creation). Alternatively via HAC (Hybris Administration Console) > Console > ImpEx Import. |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (requires SSO configuration; SCIM provisioning available on Enterprise tier per SAP Commerce Cloud documentation) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: SAP Commerce supports both disabling (deactivating) and deleting user accounts. Disabling is done by unchecking the 'Login Disabled' flag or setting account expiration. Deletion removes the record from the platform type system. SAP recommends disabling rather than deleting accounts to preserve referential integrity (e.g., order history linked to the user). Deletion of a user who owns orders or other records may cause referential integrity issues depending on cascade delete configuration.
- Log in to Backoffice Administration Cockpit with user management permissions.
- Navigate to User > Employees or User > Customers.
- Search for and open the target user record.
- Check the 'Login Disabled' checkbox (or set an account expiration date in the past) to prevent login.
- Save the record.
- For Cloud Portal users: navigate to Security > Users in the Cloud Portal and remove or revoke the user's portal access.
| Data impact | Behavior |
|---|---|
| Owned records | Orders, carts, and other records associated with the user UID remain in the system after deactivation or deletion. Deletion may cause referential integrity issues if the user is referenced by existing orders or other platform objects. |
| Shared content | Catalog entries, promotions, and other content created by the user remain in the system and are not automatically reassigned. |
| Integrations | If the user account is used for API or integration authentication, disabling or deleting it will break those integrations. Service accounts should be managed separately. |
| License freed | Not documented |
Watch out for:
- Deleting a customer who has placed orders can break order history display and reporting; deactivation is the safer approach for users with transaction history.
- Cloud Portal user removal does not affect the user's Backoffice account; both must be managed independently.
- If LDAP/SSO is in use, disabling the user in the IdP does not automatically disable the Backoffice account unless real-time sync is configured.
- Anonymous/guest customer records generated by storefront sessions accumulate over time and require separate cleanup processes.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| SAP Commerce Cloud Subscription | Platform access for all application users (employees, admins, storefront customers). Pricing is based on annual order volume or GMV, not per named seat for storefront customers. | Quote-based; $150,000–$500,000+/year depending on edition and order volume. Composable and Premier editions available as of 2024. |
- Where to check usage: SAP Commerce Cloud Portal > Monitoring section for environment metrics. Detailed license consumption reporting is managed through SAP's contract and licensing team rather than a self-service portal dashboard.
- How to identify unused seats: No built-in self-service 'unused seat' report. Administrators can query the platform database or use ImpEx/FlexibleSearch queries in HAC (Hybris Administration Console) to identify user accounts with no recent login activity (e.g., query Employee type for lastLogin attribute).
- Billing notes: SAP Commerce Cloud is priced on annual order volume or GMV (Gross Merchandise Value), not per named user seat for storefront customers. Internal employee/admin user counts are not typically the primary billing metric. Contracts are quote-based with minimum 3-month and maximum 60-month terms. Composable edition offers flexible licensing; Premier edition includes full functionality. Contact SAP or an SAP partner for current pricing.
The cost of manual management
SAP Commerce does not offer a self-service report for inactive or unused admin accounts. Identifying stale accounts requires running FlexibleSearch or ImpEx queries against the HAC (Hybris Administration Console) directly - a task that demands platform familiarity and is not accessible to non-technical admins.
Without a structured offboarding process, orphaned Backoffice accounts accumulate silently, and Cloud Portal access must be revoked separately even after a Backoffice account is disabled. If LDAP or SSO is in use, disabling a user in the IdP does not automatically disable their Backoffice account unless real-time sync is explicitly configured.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual administration is viable for teams with a dedicated SAP Commerce administrator who understands the platform's type system and user group inheritance model.
For every app in a broader SaaS portfolio, the dual-console provisioning requirement means SAP Commerce cannot be treated as a set-and-forget integration - each joiner, mover, and leaver event requires deliberate action in both Backoffice and the Cloud Portal.
Teams running B2B storefronts face additional overhead from org unit and role configuration that has no shortcut in the standard UI.
Bottom line
SAP Commerce's user management works, but it demands operational discipline that most IT and security teams underestimate at the outset.
The split between Backoffice and Cloud Portal provisioning, the absence of built-in inactive-account reporting, and the complexity of the permission inheritance model mean that access hygiene degrades quickly without a documented, repeatable process.
Teams that treat SAP Commerce like every app in their stack - expecting a single admin panel and a clean offboarding flow - will find gaps.
Budget time for both consoles on every provisioning event, and establish a recurring FlexibleSearch-based audit cadence to surface stale accounts before they become a compliance issue.
Automate SAP Commerce 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.
