Admins often need more flexibility to automate actions when machine identities or accounts change in Identity Security Cloud. This release introduces new workflow event triggers that allow organizations to extend Machine Identity Security (MIS), Agent Identity Security (AIS), and core ISC with automation that fires whenever machine identities or accounts are created, updated, or deleted. These triggers give admins fine-grained control to build workflows around the lifecycle moments that matter most.
New Capabilities
We’ve added six new workflow event triggers that fire whenever key machine identity and account lifecycle changes occur:
Machine Identity Event Triggers
Machine Identity Created
Machine Identity Updated
Machine Identity Deleted
Account Event Triggers
Account Created
Account Updated
Account Deleted
These triggers can be used to kick off downstream action like notifications, owner updates, ServiceNow updates, or any custom automation that helps teams govern identities and accounts more effectively.
Solution
The new workflow event triggers allow admins to automate actions at each key moment in the machine identity and account lifecycle. Each trigger fires when the corresponding create, update, or delete event occurs in Identity Security Cloud.
Using these triggers, admins can:
Start an owner-discovery workflow when a machine identity is created.
Send notifications when an owner list or other machine identity attributes change.
Update external systems, such as ServiceNow CMDB, when ownership or lifecycle states are modified.
Initiate follow-up actions after an account is created, updated, or deleted, such as provisioning steps, security approvals, or privileged access governance.
Our first use case is machine identity ownership governance: when a machine identity is created or updated, we’ll automatically kick off owner discovery, notify the new owner(s), and keep our CMDB / IT asset & configuration inventory aligned as ownership or lifecycle state changes.
Second, when an account is updated, we’ll watch for privileged entitlement changes and route those events into the right security approvals / SecOps steps.
We’ll use JSONPath filtering so we only trigger on high-risk scenarios (and avoid noise).
Quick question: for tenants with high event volume, is there any recommended approach for deduplication / retries so workflows can stay idempotent and resilient?
I appreciate the follow-up. Here are the dedupe/retry scenarios I’m expecting:
Dedupe scenarios
Update storms on the same object
A machine identity (or account) can get updated multiple times within minutes (aggregation, correlation, multiple attributes writes like owner + lifecycle state). That can fire several “Updated” events for effectively one logical change.
Entitlement changes applied in multiple operations
Privileged access often gets added/removed in a few sequential writes (group A, then group B), producing near-duplicate “Account Updated” events.
in case of the CMDB/asset inventory or SecOps system call fails and we retry the run (or re-run the workflow), we risk repeating side effects: duplicate notifications, duplicate tickets/approvals.
Since workflows can’t cache IDs, the “creative” approaches I’d use are:
State-based idempotency (best default): first step re-fetch current state and only act if the end-state isn’t already true (e.g., owner not already set, privileged entitlement delta still present). If already satisfied → exit early.
External idempotency key (dedupe window): generate a deterministic key like
triggerType + objectId + normalizedChangeSignature (+ time bucket)
and persist/check it in something that can enforce uniqueness (CMDB field, middleware endpoint, KV store) with a TTL (e.g., 10–30 min) to suppress bursts but still allow real future changes.
Debounce pattern: short delay (e.g., 30–90s) then re-fetch state and act once on the final “steady” state (useful for update storms).
Quick question back: do these trigger payloads include a stable event identifier (eventId) or a reliable timestamp we can use as part of that idempotency key? If not, I’ll base the signature on objectId + the specific change set (owner/lifecycle/privileged entitlements).
Thanks, @amrdodani . I had one of our engineers look into this for you.
**Do these trigger payloads include a stable event identifier (eventId) or a reliable timestamp we can use as part of that idempotency key?
**
You could use idempotency key as the combination of “workflowId” , “runId” and “TimeStamp”
workflowId & runId → Unique for every Trigger
Every Successful event Trigger has these data in the “type”:
