New Capability
Non-Employee Risk Management In-flight workflow session continuity — Audit and investigation support
Aha! Ideas Portal
- NE-I-167 — Workflow changes lead to request termination — related program context (Planned).
Description
As part of in-flight workflow session continuity, workflow configuration changes and in-flight session context are now captured in audit events and available through the Audit Events API—so administrators, auditors, and integrated tooling can investigate what changed and which workflow definition an in-flight session ran against.
Problem
When administrators update a Non-Employee Risk Management workflow configuration while there are active requests using that workflow, teams need a clear audit trail to explain what changed and why an in-flight session behaves the way it does. Today, investigation often relies on export, the live editor, or ad hoc tooling—and audit data is not consistently available to request programmatically for investigations or downstream systems.
Solution
How it worked before
-
Workflow configuration changes did not consistently produce audit events with enough context for investigations.
-
Workflow session audit records did not include the workflow version label for the definition in effect when the session started, so correlating session behavior to configuration required extra steps.
-
There was no supported way to request step- and configuration-change history for a workflow definition through the Audit Events API.
How it works now
-
Captured in audit: Dedicated audit events are emitted when workflow definitions are created, forked, deprecated, or deleted, and when workflow steps are created, updated, deleted, or reordered—each with structured payload fields (workflow identity, definition label, step details, actor, timestamp). Event types and payload fields are documented in customer API documentation {Add link}.
-
Session audit enrichment: Existing workflow session audit events include the workflow version label (workflow_version_label in the event payload) for the definition in effect when the session ran—no new session event type.
-
Requestable via API: Authorized clients use the existing Audit Events query API to retrieve and filter these events (including filters on workflow subject and definition identifiers in event data). Initial delivery is API-first; there is no new admin UI for this audit data in the first release.
API access (summary)
Configuration & lifecycle changes
- Retrieved via Audit Events API — dedicated event types for definition create/fork/deprecate/delete
Step changes (add, edit, delete)
- Retrieved via Audit Events API — dedicated step event types with definition context in payload
In-flight session context
- Existing session audit events; payload includes
workflow_version_id
Filtering
- Existing audit query API; filter by workflow subject and definition identifiers in event
data
Who is affected?
- Customers who use Non-Employee Risk Management workflows—especially IAM administrators, auditors, compliance users, and teams that integrate audit data via API.
Action required (customer-facing)
N/A for standard use. Teams that consume audit data programmatically should review the Audit Events API documentation for event types, payload fields, and supported query filters.
Important dates
Available now!
Resources
- Documentation: SailPoint Developer Community