The Apex vs. Flow debate has raged on since I started my Salesforce career over a decade ago. While clicks-not-code development has evolved to the point where Salesforce encourages it to be used in place of Apex for some situations, there are still some areas where it falls down.
One such area – a common one that I hear about often – is the lack of more complex collection types. Where Apex supports lists, sets, and maps, Flow Builder only offers a simple collection, which is a close equivalent to an Apex list. However, we’ve recently seen some commitment from Salesforce in terms of more advanced collection types coming to Flow Builder. In this article, I’ll explain what is coming and what it means for today’s Flow builders.
The Original Idea
There’s been an idea on the IdeaExchange that I’ve been keeping a close eye on for a while now – provide the ability to use Maps in Flows. It was opened over a decade ago, in 2015 (prior to the release of today’s modern Flow Builder), and has received over 1,300 votes.
The request was clear: flows allowed for collections of variables, but didn’t offer a key-value pair collection type equivalent to the map type in Apex. The OP asked for a similar mechanism to the Map<Id,sObject> format, and support for multiple levels of record collections.
A flurry of comments have continued to build up on this Idea since it was posted, and they’ve not slowed down in the decade that followed.
There’s also been numerous social media interactions across the global Salesforce community relating to this. One that caught the attention of many was related to the most recent Summer ‘26 release, where Yumi Ibrahimzade suggested that we may have map support in Flow now. This drove a lot of engagement from Salesforce professionals, and discussion around whether we’d see a true map collection type in Salesforce Flow.
Salesforce’s Update
On July 21, 2026, we finally got some positive feedback from Salesforce’s Henry Liu on the original idea. Following over 10 years of “no”, we finally got an “okay, it’s coming soon” commitment from Salesforce. Henry explained that he had received a lot of community feedback and some example use cases, and that Salesforce was finally planning to fund the development of this idea.
He explained that while HashMap functionality (storing items in key/value pairs) was important, it wasn’t top-priority for Salesforce as the majority of use cases didn’t require this. However, the most common requirement (the ability to extract related items from a collection and to filter items based on fields of records or child records) will be built as a single feature.
Henry explained that, ultimately, the goal of this new feature would be to remove the need to define your own loop to extract relevant related records. He also mentioned that there’s a new custom data type that will be coming soon, similar to Apex Defined but without the need to actually define it in Apex.
Finally, Salesforce would be making the Get Related Records feature that currently exists GA, as builders would now have an efficient way of working with the nested data. He acknowledged that while this wasn’t exactly what the OP and related comments had asked for, it would serve the same purpose once fully fleshed out, and that a generic Map collection type would be released soon after.
Expected Order of Release
While Henry didn’t provide a committed timeline, I thought it would be important to break down the different features that were coming, and place them into a rough order of release. Please note, this is based on Henry’s comments and is subject to an official release timeline from Salesforce.
Firstly, we can see from Henry’s update that the Get Related Records feature can only be made GA when there is an easier way of working with the nested collections. The first feature we can expect to be released is the ability to easily get related records out of a collection without needing a loop. Next, likely at the same time as the previous feature, is the ability to filter on a field or a related record field. This will allow builders to filter on child records without needing to set up a loop.
Salesforce is working on the custom data type alongside the above features. This means that the next feature likely to be released for Flow Builder will be the custom data type support. This will allow builders to create collections that are similar to Apex-Defined, but without requiring any Apex to be written. It’s not super clear whether this feature is coming before or after the first two, but my suspicion is that this will come in at number three.
Once these three features are available, Get Related Records will be made GA. This is because Salesforce will have met the criteria they’re looking for – a much easier way of handling nested record collections.
Finally, full HashMap support. I suspect there will be a significant period of time between the previous features and this one, based on the way Henry positioned it. It doesn’t seem like a major priority, given very few of the delivered use cases actually required it.
What Today’s Flow Builders Should Do Today
Remember that safe harbor slide at the beginning of every Salesforce presentation you’ve ever seen? The same concept applies here. Until a feature is released and GA, don’t make too many decisions based on promises.
There are existing workarounds and hacks that builders have been using for years, and all of these still work just fine. My plan is to continue to use these workarounds while keeping a register of where they’re applied so that I can update them in the future as required.
Make sure to keep an eye on the release notes to see when these new features drop, and test them out in a sandbox as soon as you can!
Summary
This is a monumental set of features that will have a profound impact on the way we build flows in the future. Countless Salesforce professionals have been asking for Map support in Flow Builder, myself included!
While the solution is being built differently than many expected it to be, I know for a fact that this will solve many problems that Salesforce Flow enthusiasts have had for years.
Is this what you had expected in terms of a solution to the lack of Map support for Flow Builder? How would you have done it differently? Let me know on LinkedIn; I’d love to hear from you!
