Summary and recommendation
Oracle 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.
Oracle Commerce (Oracle CX Commerce) is an enterprise-grade commerce platform with a role-based access control model built around built-in roles (Admin, Agent) and admin-defined custom roles. User management lives at Admin Console → Settings → User Management, accessible via your instance-specific URL at `https://<your-instance>.oraclecloud.com/occs-admin/`.
Unlike every app that ships with native SCIM support, Oracle Commerce has no native SCIM endpoint; automated provisioning requires Oracle Identity Cloud Service (IDCS) as an intermediary, which adds architectural overhead for teams expecting plug-and-play directory sync.
Quick facts
| Admin console path | Admin Console → Settings → User Management (or Roles) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full access to all admin console features including catalog, promotions, orders, settings, user management, and publishing. | Cannot exceed license-defined seat count; cannot self-assign roles beyond their own level without another Admin. | All Oracle CX Commerce subscriptions | Included in subscription; no per-seat line item published | At least one Admin account must exist at all times; the last Admin cannot be deactivated. |
| Agent | Access to Agent Console for order management, customer service, returns, and account management tasks. | Cannot access catalog management, publishing, or system settings. | All Oracle CX Commerce subscriptions | Included in subscription; no per-seat line item published | Agent role is scoped to the Agent Console only; agents cannot log into the main admin console unless also assigned an admin role. |
| Custom Roles | Admin-defined permission sets combining granular access controls across catalog, promotions, content, orders, and settings modules. | Cannot grant permissions beyond what the creating Admin themselves holds. | All Oracle CX Commerce subscriptions (custom roles are available by default) | No additional cost for custom role creation | Custom roles must be explicitly assigned to users; there is no default fallback role for new users. |
Permission model
- Model type: hybrid
- Description: Oracle CX Commerce uses a role-based access control model with a set of built-in roles (Admin, Agent) and the ability to create custom roles with granular, module-level permissions. Permissions are assigned at the role level and roles are assigned to individual users.
- Custom roles: Yes
- Custom roles plan: Available on all Oracle CX Commerce subscription tiers
- Granularity: Module-level permissions (e.g., catalog read/write, promotions, content, orders, publishing, settings, user management) configurable per custom role.
How to add users
- Log in to the Oracle CX Commerce Admin Console.
- Navigate to Settings → User Management.
- Click 'Create User' or the equivalent 'Add' button.
- Enter the required user details: first name, last name, email address, and login name.
- Assign one or more roles to the user.
- Save the user record; the system sends an activation email to the specified address.
- User must complete email-based activation to set their password and gain access.
Required fields: First name, Last name, Email address, Login name (username), Role assignment (at least one role required)
Watch out for:
- Activation email is sent immediately upon user creation; if the email domain is incorrect, the user cannot activate without admin intervention.
- Login name must be unique across the instance and cannot be changed after creation.
- If SSO/IDCS is configured, user authentication is delegated to Oracle IDCS; local password management is disabled for SSO users.
- New users have no access until they complete the email activation step.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Requires Oracle Identity Cloud Service (IDCS) integration; available on Enterprise-tier subscriptions with SSO configured. |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Oracle CX Commerce does not provide a hard-delete option for admin users through the standard UI. Users can be deactivated, which revokes their login access while preserving their account record and any associated audit history. Deactivated users remain visible in the user list with an inactive status.
- Log in to the Oracle CX Commerce Admin Console.
- Navigate to Settings → User Management.
- Locate the user to be deactivated using search or the user list.
- Open the user's profile by clicking their name.
- Toggle the user's status to 'Inactive' or click the 'Deactivate' option.
- Confirm the action when prompted.
- The user's session is terminated and they can no longer log in.
| Data impact | Behavior |
|---|---|
| Owned records | Catalog items, promotions, content, and orders created or modified by the deactivated user are retained and remain accessible to other admins. |
| Shared content | Shared content and published assets created by the user remain live and unaffected by deactivation. |
| Integrations | API keys or OAuth tokens associated with the user account may need to be separately revoked if the user had API access configured. |
| License freed | Deactivating a user does not automatically reduce the licensed seat count; Oracle Commerce licensing is subscription-based and not strictly per-named-seat in the traditional sense. Contact Oracle account management to adjust subscription terms. |
Watch out for:
- The last remaining active Admin user cannot be deactivated; the system will block this action.
- Deactivated users still appear in audit logs and historical records, which is intentional for compliance.
- If the user was the sole owner of active API credentials used by integrations, those integrations will break upon deactivation unless credentials are transferred.
- SSO-provisioned users deactivated in Oracle IDCS may still appear as active in the Commerce admin console until the next sync; deactivation should be performed in both systems.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Commerce Subscription | Admin console access, Agent console access, storefront hosting, and platform features. User seat counts are governed by subscription contract terms, not a self-serve seat counter. | Starting approximately $15,000/month; Commerce Premium Cloud tier at $800 per 1,000 page views plus $3 per additional 1,000 page views. 3-year minimum term typical. |
- Where to check usage: Oracle Cloud Infrastructure Console (cloud.oracle.com) → Billing & Cost Management → Usage Reports; or contact Oracle account management for user seat reporting.
- How to identify unused seats: No built-in 'last login' report is surfaced in the standard Oracle CX Commerce admin UI. Admins must review the user list manually for inactive accounts or request usage data from Oracle support.
- Billing notes: Oracle Commerce is sold as an enterprise subscription with usage-based components (page views). User seat counts are defined in the contract and are not dynamically adjusted through the admin console. Changes to seat entitlements require a contract amendment with Oracle. No self-serve downgrade or seat reduction is available.
The cost of manual management
Oracle Commerce has no bulk user import via CSV, so large team onboarding requires one-by-one user creation through the admin console. There is no last-login timestamp surfaced in the standard UI, meaning admins cannot identify inactive accounts without manually reviewing the full user list or opening a support request with Oracle.
Seat counts are defined in the enterprise contract and cannot be self-serve adjusted; any change requires a formal contract amendment through Oracle account management. Deactivated users cannot be hard-deleted, so the user list accumulates inactive records over time with no automated cleanup path.
What IT admins are saying
Practitioners consistently flag three friction points in the Oracle Commerce admin experience. First, the absence of bulk user import forces manual provisioning at scale, which is time-intensive for large or frequently changing teams.
Second, SSO and IDCS integration is described as complex to configure, with synchronization delays between IDCS deactivation and Commerce console status updates creating windows where deprovisioned users may still appear active.
Third, licensing opacity is a recurring complaint: admins have no self-serve visibility into seat utilization and must route all entitlement questions through Oracle account management.
Common complaints:
- Users report that there is no native bulk user import (CSV) capability, requiring manual one-by-one user creation for large teams.
- Admins note that deactivated users cannot be fully deleted, causing clutter in the user list over time.
- Community members report difficulty identifying unused or inactive accounts due to the absence of a last-login timestamp in the admin UI.
- SSO/IDCS integration is described as complex to configure, with synchronization delays between IDCS deactivation and Commerce console status updates.
- Licensing and seat management is opaque; admins cannot self-serve adjust seat counts and must go through Oracle account management for any changes.
- The admin console URL structure is instance-specific and not always clearly communicated during onboarding, causing confusion for new administrators.
The decision
Oracle Commerce suits organizations already committed to the Oracle Cloud ecosystem who need a full-featured B2B or B2C commerce platform and can absorb the enterprise contract structure.
Every app in a modern SaaS stack that handles user lifecycle more fluidly will highlight the contrast with Oracle Commerce: no bulk import, no last-login visibility, no self-serve seat management, and no native SCIM endpoint mean provisioning and deprovisioning workflows require either manual effort or a multi-layer IDCS integration.
The 3-year minimum term and usage-based pricing mean total cost of ownership is significant, and user management overhead is a secondary but real operational cost to factor in. If your identity stack runs on Okta or Entra ID, plan for IDCS configuration work before any provisioning automation is live.
Bottom line
Oracle Commerce delivers enterprise-grade commerce capabilities but pairs them with an enterprise-grade administrative burden.
Every app in your stack that handles user lifecycle more fluidly will highlight the contrast: no bulk import, no last-login visibility, no self-serve seat management, and no native SCIM endpoint mean that provisioning and deprovisioning workflows require either manual effort or a multi-layer IDCS integration.
Organizations already invested in Oracle Cloud infrastructure will find the pieces fit together with effort; those evaluating Oracle Commerce as a standalone platform should budget explicitly for identity and access management setup and ongoing maintenance.
Automate Oracle 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.
