Workflows now automatically trims HTTP POST request outputs when passed into a loop, keeping only the fields you reference in later steps. This extends the payload trimming already available for GET requests—delivering smaller payloads and faster execution times with absolutely no changes required to your existing workflows.
Problem
POST responses can be large, especially inside loops. Storing the full payload after every iteration adds overhead and clutters execution history when you only need a few fields downstream.
Solution
Automatic trimming: Loop inputs from POST steps keep only referenced fields.
Better performance: Less data stored and transferred per run.
Full output in test: Inspect all response fields while building, same as GET trimming today.
Who is affected
Workflows customers using HTTP Request (POST) whose output feeds a loop. No action is required.
I agree this is a logical feature to have and it mostly adds value (accepting the less important downside that when a workflow failed and you want to run analysis, you might not see the unused fields, even if they might be interesting).
To improve the overhead even more, the API servers that we call using the HTTP action should allow us to specify which fields to return. If those API servers allow this, then the filtering of data to send can occur server side, which means this data does not have to be send over the network at all.
For example suppose that objects exists on the external API server, where each object has 50 attributes (name, description, id, etc.), but workflows is only interested in two attributes. Right now, Workflows would get all attributes of all objects, which gets transferred through the network, and only then will workflows strip away the data to ensure when we look at past executions, we only see the required values.
This of course depends on API maturity of the external API server, to which SailPoint often has no control over.
However, SailPoint could lead by example by mature their own APIs in the same way. The search API already has this, since it supports the parameter queryResultFilter, allowing us to tell the API server to only return certain required fields. But many other ISC API’s don’t support this functionality. It can be useful as well for sources (if we are only interested in the name and owner field), identity profiles (if we don’t care about the mapping), roles (if we only care about the membership criteria field) etc. It will be beneficial to both SailPoint (since filtering out data fields is way more computational efficient compared to sending everything over the network to let it be filtered by the client) and to the caller of the API, since they would have less unimportant data to receive and process.