I have a use case where I’m building a workflow that gets triggered on an interval. 
The goal is:
-
Fetch a list of identities that meet a specific identity attribute
-
Loop through that list
-
Disable an account from a specific source for each identity
To get the list of identities, I’m using the “Get List of Identities” action with a search query. This returns a list, so I naturally use a loop in the next step.
Now, inside that loop, I want to get a specific account for each identity. I don’t want to disable all accounts. If I use the “Get Accounts” action, it returns a list again, and I can’t use a loop inside a loop (limitation of the current workflow engine).
My workaround:
I’m using an HTTP Request inside the loop to call the v2024/accounts API and fetch the specific account ID for that source. Then I simply call the Disable Account action using that ID.
The problem:
While testing, I noticed that the “Get List of Identities” step is loading all identity data—even though I only need the identity ID. 
This is causing performance issues, even with just 152 identities matching the condition.
It feels like I’m forced to use this action, even though it’s giving me way more data than I need.
The simple solution 
Introduce a “Connections” concept in workflows:
-
Let us connect to an endpoint (like IDN) once
-
Reuse that connection throughout the workflow
This would drastically reduce dev effort AND avoid the need for half-baked or redundant actions that often don’t help much and sometimes complicate things.
Most low-code/no-code platforms have Connections as a fundamental building block. Why doesn’t SailPoint provide this?
Would really appreciate if someone from the product team could chime in and help us understand the reasoning here.