Straight answer: the Transform element maps one collection onto another, field by field, without a Loop and without an Assignment element per field. It is the right tool when the work is pure reshaping: turning a collection of Opportunities into a collection of Cases, flattening a query result into the input structure an invocable action wants, or aggregating a collection down to a single total. It is the wrong tool the moment the mapping needs branching logic or a database call per item.
What it does
Drop a Transform element on the canvas and you choose a source, a target, and then draw the mapping between them in a two-panel editor. Source on the left, target on the right, a line between each pair of fields. The element produces a new resource holding the result, which you then pass to Create Records, to an action, or to a screen component.
The source can be a collection or a single value. The target can be a collection of any object, an Apex-defined type, or a simple variable. A collection in, a collection out, with one output item per input item is the common case.
What it saves you
Before Transform existed, converting fifty Quote Line Items into fifty Order Products meant a Loop, an Assignment inside it setting eight fields on a record variable, a second Assignment adding that variable to a collection, and a Create Records after the loop. Five elements and a maintenance problem, because adding a ninth field meant editing an assignment buried inside a loop.
Transform replaces the loop and both assignments with one element whose entire content is the mapping. When somebody asks you to carry one more field across, you open the element, draw one more line, and the change is obvious in review.
Formulas inside the mapping
A mapping line does not have to be a straight copy. Each target field accepts a formula, evaluated per item, with the source item available to it. That covers concatenation, type conversion, defaulting, and simple conditionals:
IF(
ISBLANK({!sourceItem.Description}),
"No description supplied",
LEFT({!sourceItem.Description}, 255)
)This is where the boundary sits. A formula can choose between two values for one field. It cannot decide to skip an item entirely, and it cannot produce a different number of output items than input items.
Aggregation
Transform also collapses a collection into a single value. Set the target to a number variable, pick the source collection, and choose a count or a sum over one of its fields. That gives you “total amount across these line items” or “how many of these are overdue” in one element, with no running total variable and no loop.
Combined with the Collection Filter element, this covers most of what people used to write loops for. Filter the collection to the items that matter, then transform it to a sum.
Where it does not fit
- Conditional inclusion. If only some source items should produce an output item, filter the collection first with Collection Filter, then transform what survives.
- Anything needing a query. Transform has no access to the database. If the target field needs a value looked up per item, query once before the element with an In filter and map from the result.
- Many-to-one or one-to-many. Producing three records from one source item is loop work.
- Side effects. Transform creates nothing. The output lives in memory until a Create Records element takes it.
Deployment and review
The mapping is stored in the flow metadata, so it deploys like any other element and shows in a diff as changes to the flow XML. That diff is not pleasant reading, which is an argument for keeping the mapping obvious and the field names sensible rather than relying on the diff to explain a change.
One practical note for teams: a Transform element with thirty mapping lines is much easier to review in Flow Builder than the equivalent thirty assignment rows spread over three elements, and much harder to review in a pull request. Screenshot the mapping in the change description if your process needs a reviewer who is not going to open the org.
Frequently asked
Does Transform save records? No. It builds a collection in memory. Follow it with Create Records or Update Records.
Can the source and target be the same object? Yes. Mapping Account to Account is a valid way to build a modified copy of a collection without touching the original.
Can I map into an Apex-defined variable for an invocable action? Yes, and this is one of the better uses of it. Building the input structure for an Apex action used to need either a loop of assignments or an Apex wrapper.
