Correlating ENTITLEMENT_ADD/REMOVE events with workflow executions in Identity Security Cloud

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, ,
1

Hi everyone,
I’m working on a SailPoint Identity Security Cloud tenant and I have an architectural/practical question about troubleshooting access changes.

In my environment I have several workflows acting on identities and accounts (e.g. a joiner workflow that assigns base groups/entitlements, workflows that clean AD groups when an account is disabled, workflows that re‑apply base groups when the account is re‑enabled, etc.).
After a few months, when I need to analyze what happened to a specific user or account, I would like to know:

  • which workflows have been executed for that identity/account
  • which *specific* workflow execution caused a given add/remove entitlement or AD group event

What I see today is:

  • in Access History / Cloud Audit I can see events like `ENTITLEMENT_ADD` / `ENTITLEMENT_REMOVE` (or similar), with identity/account and timestamp
  • separately I can see/expose workflow executions (workflowId, runId, timestamp, trigger, and so on)

The issue is that **the ID of the entitlement add/remove event does not seem to have any direct link to the ID/Run ID of the workflow execution that caused it**. Starting from an audit event on an entitlement or an AD group, I can’t reliably trace back to the workflow (and the specific run) that generated that operation.

What I would like to achieve, for example, is:

  • for the identity “Mario Rossi”, to see that there were N different workflow executions over time, each with details of what they did (add/remove entitlements, reset password, etc.)
  • for the AD account “m.rossi”, to be able to say: “10 workflows have acted on this account, here are the workflowId/runId values and here are the accesses they changed”

My questions are:

  1. Is there currently any **supported** way in ISC (APIs, Search, Cloud Audit, list‑workflow‑executions, etc.) to reliably correlate events like `ENTITLEMENT_ADD_PASSED` / `ENTITLEMENT_REMOVE_PASSED` with the `workflowId` / `runId` of the workflow execution that triggered them?

  2. Is there any recommended best practice to obtain a view like “all workflow executions that acted on this identity/account” without having to implement custom logging in every single workflow (for example an HTTP step to an external log with identityId/accountId + workflowId/runId + operation)?

  3. From your experience, are there any common patterns (identity tagging, custom audit events, etc.) that you use as a workaround until there is a native linkage between audit events and workflow executions?

The goal is to improve troubleshooting and audit after the fact: when I start from an entitlement add/remove event, I’d like to clearly trace back to the workflow that generated it and have a complete timeline of workflows executed for a given person or account.

Thanks in advance for any clarification, documentation reference, or practical example you can share

2

Hi @ffalcitelli - With the recent addition to ISC search called “Workflow History”. If you have the entitlement ID, or an access request ID, or an identity ID, you can search with double quotes to get everything workflow-related for your search term. You can narrow that ISC search query down as you need to. Does that work for you?

3

Can you give me some example ?

I have some workflows with the block “Manage Access” that adds or remove entitlements.

Than, with the search filter: name:“Add Entitlement Passed” I can see the events of Add Entitlements in success for all users (in target i have the username, for example 123456).

I think i need to search the workflow history the rows with step name=“Manage Access” and something 123456 ? Right ?

Do you have some examples of filters or some use cases ?

Thanks

4

Right, something like this should narrow down specific workflow events:

workflowName:"Your Workflow Name Here" AND attributes.displayName:"Your Step's Display Name Here" AND attributes.result.exact:/.*123456.*/

That’s if you want to find workflow events with 123456 in the output of the step.

5

Hi @ffalcitelli … I tried to give some of the answers to your questions see if this helps:

This is a well-known limitation within SailPoint(ISC). As per the situation there is a fundamental decoupling between the Identity Provisioning Engine which commits transactions and logs ENTITLEMENT_ADD_PASSED and the Workflows Engine which triggers those actions via API or internal integration.There is no built-in mechanism to directly trace a downstream transactional audit event back to its parent workflowId/runId.

There is currently no OOTB API, search attribute, or schema payload entry within the Cloud Audit service that embeds the runId or workflowId into an ensuing ENTITLEMENT_ADD_PASSED or ENTITLEMENT_REMOVE_PASSED event.

Solution to your problem as of now - Configure subscriptions to the Provisioning Completed or Saved Search Results event triggers and forward the payloads via a central webhook/Logstash pipeline to external platforms such as Splunk for audit and analytics purposes.

https://community.sailpoint.com/t5/Identity-Security-Cloud-Wiki/SailPoint-Identity-Security-Cloud-AuditEvent-Add-on-for-Splunk/ta-p/77123

6

@ffalcitelli

Currently, there is no native or supported correlation ID in SailPoint ISC that directly links an entitlement add/remove audit event to the specific workflowId/runId that triggered it.

Short answers to your questions:

  1. Direct correlation?

    • No. Audit events, provisioning events, and workflow executions are stored separately, and there is no out-of-the-box linkage between entitlement audit events and workflow run IDs.

  2. View of all workflows acting on an identity/account?

    • Not natively. You can review Workflow Executions, Cloud Audit, and Search data independently, but ISC does not provide a consolidated timeline showing which workflow modified which entitlement.

  3. Recommended workaround?

    • The most common approach is to implement custom logging within workflows. For example:
      • Log identityId, accountId, workflowId, runId, operation performed, and timestamp.
      • Send the data to an external system (Splunk, Sentinel, ServiceNow, database, etc.).
      • This creates a complete audit trail and makes troubleshooting much easier.

Best Practice: Add a logging step at key points in your workflows, especially before provisioning actions. Capture the workflow context and target identity/account details. This provides the only reliable way today to trace an entitlement change back to a specific workflow execution after the fact.

For complex environments with multiple automations, maintaining an external workflow audit log is generally considered the most scalable and supportable solution.