The Salesforce Summer ‘25 release has already reached production instances, with many exciting new features that Salesforce professionals can use to enhance existing processes or support new ones.
Flow Builder has seen numerous improvements over the past few releases, but this one might just be the most over-the-top one yet – with an overhauled Debug panel, the option of visual choices, Time Available as a data type, and even a Has Error operator for Flow Tests. In this post, we will zoom in on the brand new ‘also get related records (beta)’ option when using the Get Records element.
The Get Records Element
First things first, let’s discuss the Get Records element within Flow Builder and why it is so widely used!
Simply put, this element is the liaison between your automation and Salesforce (or Data Cloud) data. While there are other ways to bring information within the flow, depending on the use case and the type of flow used, more often than not, there will be a need to query one or more records, usually based on criteria. This is where the Get Records element comes in.
The output of this element can then be used within your flow to perform calculations, display data, and even make updates. Practically, it is everything that you may need to use Salesforce data for when it comes to creating bespoke automations.
Until now, the Get Records element only allowed you to retrieve records for one type of object at a time, meaning that in a scenario in which you need to retrieve Opportunities and Opportunity Products, for example, that would have resulted in two separate elements and queries towards your database in the background. While in some cases this will still be needed, what if retrieving records related to the same ‘parent’ object could be much optimized?
One Get Element, All Related Records (Beta)
With efficiency being top of mind for automations, it’s no wonder that this new beta enhancement to the Get Records is an exciting new addition! When using the Get Records element following Summer ‘25, the option to also retrieve related records can be selected – it doesn’t have to be enabled, it will simply be present to use when needed.
Available for Autolaunched Flows, getting the entire hierarchy of related records in one single step is bound to make your flows cleaner, easier to read, and ultimately require significantly fewer clicks to maintain or adapt.
After choosing the main object and enabling the option to ‘also get related records (beta)’, you will see a significant difference in experience compared to the single-object Get Records element we’re familiar with. Starting from the Opportunity object in this example, you can pick and choose all related records you need, then start defining the fields for each one of them.
For each of the objects, including the Opportunity, you can optionally add filters, determine the sorting, and how many records to store. When working with multiple related objects, the table on this modal comes in handy to determine which of them has filters applied. So, in case the output doesn’t contain all the records, you will know that filters exist and may need tweaking. Isn’t that great?
Once the final objects and their attributes are determined and saved within the modal, the Get Records panel will display the hierarchical breakdown, with an option to expand or collapse to review the details of every variable and which fields are included.
Similar to any other process or automation, you don’t have to set everything from the get-go, especially when exploring how a new features works for your use case – you can always come back and add more fields or objects as needed, tweak the filters or filter logic, or remove the fields or objects altogether which are no longer needed.
See It in Action
If one thing is certain, it is that there are a myriad of use cases the Get Records element can be used for – even more now that getting related objects at the same time is an option. Let’s dive into a basic example of what is possible!
Before using the data retrieved with the Get Records element, keep in mind that the output is not directly accessible for later use in its entirety – the related records retrieved should be assigned to variables available for output for use outside the flow. In this case, those are the Opportunity Products and the Opportunity Contact Roles.
Also, remember to only select the fields you need from each object to avoid unexpected issues when the flow is triggered. While this may not happen often, it’s always a better idea to be specific with what is needed, then expand if requirements change down the line.
With the aforementioned in mind, let’s see the output in action within a Screen Flow, which will be accessed through a button on the Account record, to offer sales managers a quick overview of the Account with just one click!
The flow itself already has a Get Records element to retrieve all Opportunities associated with the Account, an Action to invoke a Prompt Template for the Account Summary, and one screen where all information will be displayed. The Autolaunched Flow above comes into play as a Screen Action, as the desire is for the related records to only be displayed once the Opportunity is selected on the first data table.
At this time, it isn’t possible to traverse relationships when selecting the fields for the related records within the modal. For example, when it comes to the Opportunity Contact Roles, the Contact Name is not available immediately. Since using any of the standard fields wouldn’t offer a great experience for the sales manager, a potential next step is to create a formula field to display the Contact’s name or email in the table when using the collection variable as the source.
Of course, you will have to determine how you want the data to be displayed, any component filters or additional instructions that should be added, and if anything else should happen on top of displaying the information. This example, however, is just an informational one, so let’s see it in action on an Account!
After creating the Action and adding it to the Record Page (or page layout if you’re not using Dynamic Actions), let’s see what a sales manager would be met with:
- The prompt output at the top of the screen displays the Account summary with key information about the customer.
- The table with all Opportunities from this Account, sorted by their Close Date – here is where, in a real-life scenario, additional instructions or a table header could be a good addition for clarity to ensure that the expected next step (selecting one of the Opportunities) is known.
- Then, once an Opportunity from the table is selected, the list of Products and the list of Opportunity Contact Roles appear as intended, meaning that they have been successfully retrieved through the Autolaunched Flow invoked by the Screen Action.
Final Thoughts
Having the ability to retrieve everything you need and subsequently perform various data operations with less complexity is not only a nice enhancement but a significant optimization that all Salesforce professionals using Flow can tap into. Forget about the separate Get Records elements for related objects, and the hassle that comes with maintaining every one of them when it comes to updates.
Have you already tried out the new Get Records update? Let us know in the comments below!
