We are currently using SailPoint version 8.4 Patch 2 and have recently integrated ServiceNow with SailPoint.
We have a business role that is mapped to multiple IT roles. Each IT role is associated with different application entitlements, and some of these applications have disconnected entitlements, which are delimited applications.
When a user requests this business role, the access request generates separate RITMs (Request Item Tickets) for each application. We have Native Change Detection (NCD) configured for each application.
However, when we close one RITM for a specific application—changing its status from “Pending” to “Completed” in SailPoint—while other application RITMs within the same access request remain in a “Pending” state, we then aggregate the completed application’s data. This triggers aggregation for that application and creates the user in that application. Subsequently, in the identity XML for that identity, we are noticing that entitlements from other applications within the same access request (which are not related to the current application) are appearing as “removed” in the triggered snapshot of native change.
Could you please help us understand why these unrelated entitlements are showing up as removed values in the identity XML?
The three approaches outlined are all valid ways to prevent unrelated entitlements from appearing as “removed” in your Native Change Detection snapshots:
Scope NCD via Connector Configuration - The simplest, configuration-only change. By adding an and disabling deletes (includeDeletes=“false”) in your ServiceNow connector definition, NCD will only snapshot the entitlements for the application tied to the RITM being completed. All other entitlements remain out of scope and will not be reported as removed.
Per-Application Aggregation Tasks – A declarative, best-practice approach. Defining a separate aggregation task for each application and mapping each IT role to its own task means that closing a RITM only triggers its specific aggregation job. As a result, NCD never sees entitlements for other applications and cannot flag them as removed.
Custom Native Change Detector – An advanced, code-level solution. By subclassing SailPoint’s NativeChangeDetector and overriding its snapshot-filtering logic, you gain full control over which entitlements are included in “before”/“after” snapshots. This is the most flexible approach but requires Java development and proper registration in your iiq-config.xml.
depends on your organization’s needs:
For quick fixes and minimal effort, start with Approach 1.
If you prefer clear separation of aggregation scope with no coding, use Approach 2.
If you need dynamic, context-aware filtering beyond what XML config allows, implemen
