Requests are auto-forwarded to the provisioning instance.
Since the Access Request Portal lacks direct connectivity to targets, it relies on CSV feed files (source of truth) for aggregation and auto-reconciliation.
A request is only marked complete if the next CSV feed confirms the provisioned access. Otherwise, it remains stuck in:
Committed (most common: wrong account name used)
Verifying
Incomplete
**Key Issue:**
Users request access using their UID in SailPoint, but provisioning occurs on the target system’s LoginID/AccountName.
The next feed file reflects the access tied to AccountName, not UID.
During aggregation, SailPoint creates a new link object (correlated to the identity), while the original UID-based request stays in Verifying.
Root Cause: Verification appears to require a match on (UID + EntitlementName + AccountName). If the feed file’s AccountName differs from the request’s UID, the request fails verification.
<strong>Question:
Is it possible to <strong>modify the verification logic to rely **only on (UID + EntitlementName), ignoring `AccountName?This could significantly reduce false "Committed" statuses caused by account-name mismatches.`**</strong></strong>
**Additional Notes:**
Has anyone implemented a similar workaround (e.g., custom correlation rules, feed transformations)?
Are there risks to this approach (e.g., false positives, compliance impacts)?
@gbessomba This requires heavy customization on a core executor: IdentityRequestMaintenance which is responsible for validating the access request. I would not recommend this.
Could you please confirm where there is a mismatch on native identity during provisioning vs aggregation?
Note: Found a fix? Mark it as a solution! Want to say thanks? Give Kudos to anyone who helped you understand or solve the problem. Thanks..!!!
Thanks for your guidance. I investigated further and confirmed that there is indeed a mismatch in the native identity.
In our case:
The aggregation feed uses LoginID as theaccount identitfier( native identity)
However, provisioning is based on a different identifier (UID)
Additionally, the csv contains a GlobalUID field, which correctly maps to the identity in SailPoint.
So during aggregation:
SailPoint correlates the account to the correct identity using GlobalUID
But the native identity (LoginID) differs from the one used during provisioning
This explains why a new link is created, but the request remains in a “verifying” or " commited" state.
For your information,each application can have its own AccountName/LoginID. In most cases, the AccountName matches the UID in SailPoint, so this is not a problem for the current scenario
From my analysis, correlation already seems to be working correctly in our case, as the accounts are properly linked to the identities using the GlobalUID from the feed.
However, the issue appears to be related to verification rather than correlation. Specifically, there is a mismatch between the native identity used during provisioning and the LoginID returned in the aggregation feed.
As a result:
- SailPoint successfully correlates the account to the identity,
- But the request remains in “Verifying” or “Committed” status because the native identity does not match the one used in the original request.
Given this, I’m not sure updating the correlation logic alone would resolve the issue.
Would you recommend instead focusing on aligning the native identity between provisioning and aggregation, or handling normalization during aggregation
Regards
@gbessomba You rightly mentioned about the Verifying. As the native id is not matching between access reuqest vs the one coming via aggregaiton, it remains on verifying. So we should fix it. Either do it during aggregation or do it during provisioning, but just make sure both should be same.