Hello, I have a request to create a workflow in ISC that will run through inactive identities and return any identities that have accounts that are not disabled 30 days (1 day for testing) after those identities have been set to inactive. This should result in an email of identities with active accounts.
I have a workflow validated, but I do not have any meaningful results from this process.
I have attached a screenshot of a simplified version of this workflow of testing
Get list of disabled identities > Loop through identities > Get accounts > Compare the timestamp of identities > Compare how long the identity has been disabled > Send email if accounts are enabled past threshold > end.
Any ideas what I should be doing here differently?
For good measure I have given the Harbor Pilot several tries at this ask, each failing to perform any action or failing to validate the workflow with significant corrections needed.
I would suggest using Identity Lifecycle State Changed, filtered for newLifecycleState = inactive.
Then:
Wait 30 days → confirm the identity is still inactive → Get Accounts → check disabled == false → Send Email
This avoids using the identity modified timestamp, since that represents the last modification to the identity, not specifically when it became inactive.
This approach runs per identity so that each match would generate its own email. If you need one consolidated summary email, your scheduled workflow with a loop is the better approach.
Your approach looks promising. However, the timestamp comparison may not work reliably in this scenario. Instead, use an HTTP operation to retrieve the exact details you need through a search operation, and then compare the values using a greater-than (>) operator. That approach should work as expected.
How is the comparison being performed in your case to determine whether it is 30 days for the user in inactive state.
Do you have leaving date information stored in some identity attribute like end date. If you are storing the end date information, then i think your approach is fine, and you can use the search query some thing like below to even enhance the workflow further and get filtered identities.
attributes.endDate:[now-30d/d TO now-30d/d] AND @accounts(disabled:false )
If you want to exclude some sources here, then you can even extend this query like below
attributes.endDate:[now-30d/d TO now-30d/d] AND @accounts(disabled:false AND NOT(source.name:IdentityNow))
I think this then will ensure that you do not need to perform the comparison inside the workflow and you will get filtered results from query itself.
There is a limitation of number of items that can be iterated in the workflow. Did you consider that limitation also before choosing to implement this logic in workflow ?
