Recursive Workflows in IdentityNow

[colin_mckibben]

@jasmedina

Is there a workaround or other alternative we could use aside from Recursive Workflow if we need to have the context defined inside the loop? Thank you!

I have yet to find a way to provide context in recursive workflows.

[angelo_mekenkamp]

We need to have a workflow that loops over objects in ISC. It does not matter if it occurs recursively or in parallel.

ISC uses offset and limit in their list APIs (at least most of the time, this convention is not always used), which is great and shouldn’t be changed.
However, SailPoint workflows is quite limited. One limitation is that it can’t work with pagination.

Our workflow should be an external trigger and as input it should get an offset, initially 0. What we then want to do boils down to this pseudocode:

def my_workflow(int offset)
   results = get_objects_through_HTTP_operation(url='/v2024/something', limit=50, offset=offset)
   if results.size == 0
      return
   else
      new_offset = offset + 50
      my_workflow(new_offset)
      foreach result in results
         do_something(result)
      end
   end
end  

Since SailPoint ISC does not offer this easy simple type of coding, we would as workaround need to create a very complex and long to build workflow to achieve something similar. However, it looks like the workflow functionality of SailPoint is not able to count. We can’t define a variable new_offset as the previous offset+50, nor can we perform some kind of increment action 50 times.

Note that the SailPoint workflow is not compatible with the default limit of SailPoint objects, as the former can only support of to 50 records while the latter has a default of 250 objects. This is why I specifically downgraded the limit to 50.

As workaround on top of this workaround we might need to use the HTTP operation to call a server that is actually able to add 50 to a given number? I don’t think SailPoint customers should have to rely on third party software to perform addition or any other very basic calculations.

Kind regards,
Angelo

[adamian (Andrei Damian Fekete)]

@angelo_mekenkamp

One limitation is that it can’t work with pagination.

Any progress on this front? Did the SailPoint architects have any suggestions on how to improve this?

It seems wasteful to limit the loop to 100 objects (to avoid excessive usage of resources), just to replace the loop with N thousand invocations. And also to get the situation that you can’t list the workflow executions anymore as there are too many of them.

[colin_mckibben]

No progress on this front yet. However, workflows is getting some performance upgrades that may allow the team to up the loop limit soon.

[sharvari (Sharvari Bharatiya)]

@colin_mckibben

up the loop limit soon

If they can do that, it would be awesome! Please keep us posted if you get any updates on this.

[adamian (Andrei Damian Fekete)]

@colin_mckibben

I will demonstrate how to implement recursion in Workflows to achieve looping behavior without the need for the loop operator.

This seems to go head to head with the newly introduced limits:

Rate Limits for Workflows

Announcing Workflows Rate Limits To enhance your experience with SailPoint’s Identity Security Cloud, we are introducing updates to SaaS workflows starting January 16, 2025. Some workflows generate an exceptionally high number of executions daily, causing system-wide lag and impacting service quality for all tenants. To maintain system stability and equitable performance, we’re implementing standardized workflow execution rate limits that are fair and sufficient for meeting customer business nee…

Are these recursive workflows still recommended by SailPoint?

[colin_mckibben]

The workflow rate limit is set pretty high. Most customers should not hit the rate limit. While runaway recursion can cause high workflow executions, even a workflow with loops or no looping at all can cause issues. For instance, if you create a workflow that uses the Identity Attributes Changed event trigger without a trigger filter and you run an aggregation on a source that has changed many of the account attributes, you could reach the rate limit without any looping involved. Adding a loop to this could compound the issue.

Recursion should not be the first choice, but it is an option if you are willing to deal with the complexity. I recommend using recursion with caution and handle any edge cases that may cause a high number of executions.