I create a Workflow to Uncorrelates account from main identity but after JDBC source aggregation, accounts correlates again.
Use HTTP operation to uncorrelates the account.
asking your advice on this thanks..
I create a Workflow to Uncorrelates account from main identity but after JDBC source aggregation, accounts correlates again.
Use HTTP operation to uncorrelates the account.
asking your advice on this thanks..
Hi @RANONU-C
Please elaborate your requirement here.
Even if you manually uncorrelate the account, it will correlate on next aggregation if it finds any Identity matching the correlation criteria.
Welcome to the SailPoint Developer Community @RANONU-C
Here are a few approaches to solve this depending on your use case:
If you are dealing with disabled accounts on termination - The cleanest approach is to exclude terminated/disabled accounts from aggregation entirely by modifying your Account SQL Query with a WHERE clause like:
SELECT * FROM TABLE_NAME WHERE STATUS != 'TERMINATED'
This way, terminated accounts are never aggregated, and re-correlated. You may use a Correlation Rule if the accounts can be logically categorized.
If you still need to aggregate all accounts for audit/compliance/rehire scenario but want them to be uncorrelated based on a workflow trigger consider reassigning account instead of removing correlation.
Reassign the account to a Dummy/Service Identity via API
Practical fix that works within your existing workflow approach, instead of removing the identityId, replace it with a designated service/dummy identity using the Update Account API:
PATCH /v3/accounts/{accountId}
[
{
"op": "replace",
"path": "/identityId",
"value": "<your_dummy_identity_id>"
}
]
Why this works
When you use "op": "remove" on /identityId, the account becomes uncorrelated but the next aggregation re-evaluates and re-correlates it as @sidharth_tarlapally explained. When you use "op": "replace" instead, ISC automatically sets manuallyCorrelated: true on the account. This flag tells the aggregation engine to respect the existing correlation and skip re-evaluation, so the account stays pinned to the dummy identity across aggregations.
![]()
Thanks,
Amar