The Situation
Identity and access management in modern enterprise environments often involves a mix of provisioning strategies. In SAP's Sales & Service Cloud v2 (SSCv2) & SAP Enterprise Service Management (ESM), it is common to find tenants where some users are created manually by administrators while others are provisioned automatically through SCIM (System for Cross-domain Identity Management). This hybrid approach seems harmless — until you run a SCIM replication job and discover that manually created users have silently lost all of their assigned roles.
This is not a random glitch. It is a predictable, reproducible behavior rooted in how SCIM-enabled tenants manage role assignments — and understanding it is the first step to preventing it.
The Problem
In a SCIM-enabled SSCv2 tenant, users who were manually created (i.e., not provisioned through SCIM) and had business roles manually assigned to them lose those role assignments whenever a SCIM replication process runs — even though these users are not managed by SCIM at all.
What makes this particularly puzzling is that the Cloud Identity Service (CIS) logs show no record of updates to those manually created users during the replication run. From the system's perspective, nothing happened — yet the roles are gone.
How to Reproduce It
The issue is entirely reproducible. Here is the sequence of events that triggers it:
- Create a user manually in SSCv2 (outside of any SCIM provisioning flow).
- Assign one or more business roles to this user directly in SSCv2.
- Create a second user via SCIM provisioning from the Cloud Identity Service (CIS).
- Assign the same roles to the SCIM-managed user through CIS.
- Execute the SCIM replication process.
- Check the manually created user's role assignments.
Result: The manually created user's role assignments have been removed. The SCIM-managed user's assignments are intact. The CIS logs contain no trace of any action against the manually created user.
Why This Happens: The Root Cause
The behavior is not a bug in the traditional sense — it is a consequence of how role replication works in a SCIM-enabled tenant.
In SSCv2, when SCIM is enabled, the authoritative source for role assignments is Identity Authentication Service (IAS), not SSCv2 itself. The replication flow works as follows:
- Roles are replicated from SSCv2 to IAS via replication jobs.
- User-role assignments are replicated from IAS back to SSCv2 via those same jobs.
This means that during a replication run, SSCv2 does not selectively update only SCIM-managed users. Instead, it synchronizes role assignments based on what IAS reports. If a role is assigned to a SCIM-managed user in IAS, that assignment gets written to SSCv2. But because the manually created user has no corresponding record in IAS, the replication job effectively overwrites the role assignment state for that role — removing it from any user not represented in the IAS replication payload.
The silence in the CIS logs is explained by the same mechanism: CIS did not act on the manually created user. The removal is a side-effect of the IAS-driven synchronization overwriting what SSCv2 holds locally.
The Fix: Make Manually Created Users SCIM-Managed
The resolution is straightforward once the root cause is understood: manually created users need to become SCIM-managed users.
The recommended approach is to:
- Replicate the manually created users to IAS — either by re-creating them through the SCIM provisioning flow or by synchronizing them into IAS via the appropriate identity provisioning job.
- Allow IAS to replicate them back to SSCv2 so that SSCv2 recognizes them as SCIM-managed identities.
Once a user is SCIM-managed, the replication process treats their role assignments as part of the IAS-controlled state. Role assignments will no longer be removed during replication — they will instead be preserved and managed consistently alongside all other provisioned users.
What This Means in Practice
If your SSCv2 tenant is SCIM-enabled, the following rules of thumb apply:
| Scenario | Risk |
| User created manually, roles assigned manually | High — roles will be lost on next replication |
| User created via SCIM, roles assigned via CIS/IAS | Safe — roles are managed within the replication loop |
| User migrated to IAS and replicated back to SSCv2 | Safe — user is now SCIM-managed |
The key principle: in a SCIM-enabled tenant, IAS is the source of truth for role assignments. Any role assignment that exists only in SSCv2 — without a corresponding entry in IAS — is at risk of being overwritten during the next replication cycle.
Recommendations
- Audit your tenant for manually created users who have business roles assigned. These are the users at risk.
- Do not mix provisioning strategies for the same set of roles. If a role is managed via SCIM, assume that all assignments for that role will be governed by the IAS replication process.
- Migrate manually created users to IAS before the next replication run if they need to retain their role assignments.
- Establish a governance policy that requires all new users in SCIM-enabled tenants to be created through the provisioning pipeline, not manually.
- Monitor replication logs proactively — the absence of entries in CIS logs does not mean nothing changed in SSCv2.
The Golden Rule: SCIM Is a Day 1 Decision
If SCIM will ever be used in your SSCv2 tenant — even in the future — it must be architected from Day 1.
This is not a configuration preference. It is a foundational architectural decision with production consequences. Here is why:
| Scenario | Risk | Level Consequence |
| SCIM enabled before any user creation | None | All users are provisioned consistently via IAS |
| SCIM enabled after manual users already exist | High | First replication job silently removes role assignments |
| Manual users migrated to IAS before next replication | Medium | Recoverable — but requires careful, urgent remediation |
| Manual users NOT migrated before replication runs | Critical | Users lose access in production, no CIS log trace |
Even if SCIM is not required at go-live, if there is any possibility it will be introduced later — plan for it now. The cost of retrofitting the provisioning model after manual users are established far exceeds the effort of doing it correctly from the start.
Summary
The loss of role assignments for manually created users in SSCv2 is not a random failure — it is the predictable outcome of a SCIM-enabled tenant architecture where IAS owns the user-role assignment state. The fix requires aligning manually created users with the provisioning model: replicate them to IAS and back to SSCv2, making them SCIM-managed. Once that alignment is in place, the replication process will preserve their role assignments rather than silently remove them.
If you are operating a hybrid environment where both manual and SCIM-provisioned users coexist, this issue is likely already affecting you. Addressing it proactively — before the next replication job runs — is far less disruptive than recovering from unexpected access loss in production.
Flow 1: The Problematic Scenario — SCIM Not Planned From Day 1
This is what happens when SCIM is introduced or enabled after users have already been created manually in SSCv2+ESM.
Key Insight: The damage is silent. CIS logs show nothing. The role removal is a side-effect of IAS overwriting SSCv2's local role assignment state — leaving no audit trail pointing to the affected users.
Flow 2: The Correct Approach — SCIM Planned From Day 1
This is the recommended architecture when going to production. SCIM must be the only provisioning channel from the very beginning.
Source link
