Apex-Defined Data Types in Flow

Hey, Trailblazers!

During a recent Salesforce Platform App Builder training session, we dedicated substantial time to Salesforce Flow development. The audience was a mix of admins, developers, and architects. A developer asked about this challenge in Flow development: When writing Apex code, we tend to have utility classes that define common variables to use in all apex class. This feature was not available with flow. There didn’t seem to be a way to reuse a common set of variables from flow to flow.

This observation led us to explore the potential of Apex-defined data types in Salesforce Flow, aiming to achieve similar efficiency. Imagine a scenario where your company seeks to gather extensive customer data across various objects through a single screen in a screen flow, potentially across multiple flow versions. Each flow requires manual definition of all resource variables each time a new flow was needed. If using common data structures with dozens of data points this could be a time consuming and error prone activity.

To demonstrate the issue and solution I wrote two screen flows. The first flow captures first and last name, age, and then queries an account to get a record. The flow will call a subflow which is also a screen flow in order to display the values.

Each Flow world have the same resource variables defined:

The main flow would use the Subflow Element to pass the four variables

The subflow would display the passed data using a display text component on a screen element

Here are the two flows with data being passed using 4 variables:

Introducing an Apex Data type would greatly simplify the development of these flows.

Apex-defined data types offer a solution by encapsulating these parameters into a single, reusable class. Consider creating a awGlobalVariables class, a container for all variables. It streamlines the development process as follows.

Here is an Apex Data type to replace our 4 variables

The awGlobalVariables class is like a container that holds information about a person and their associated Salesforce account. It's designed to keep track of certain details such as the person's first name, last name, age, and information about a Salesforce account.

Public Class: The term "public" indicates that this container or class can be accessed from other parts of the Salesforce system. It's like saying this container is not hidden; it can be seen and used by other parts of Salesforce.

@AuraEnabled: This label before each piece of information (like first name, last name, etc.) means that these details can be displayed or modified through Salesforce's user interface components, particularly those built with Aura, Lightning Web Components and Flow. It's a way of saying, "Yes, you can show or change this information on the Salesforce screens."

Stored Information

• firstName: This is a space in the container for storing a person's first name. It's like a label on a shelf that says "First Name," where you can place the actual first name of a person. In Flow String data type is Text.
• lastName: Similar to the first name, this is a space for the person's last name. Another label on another shelf, this time saying "Last Name."
• age: Here, instead of text, you can store a number representing the person's age. Think of it as a specific spot for holding numerical values. In flow the data type would be Number with 0 decimal places.
• myAccount: This is a bit different from the others. Instead of just storing a simple piece of information like a name or a number, this space is reserved for storing details about a Salesforce account. In flow this would be the same as a resource variable whose data type is Record and the object is Account. .

To create an Apex Defined data type in flow we would define a new resource as a variable but we would choose the data type as Apex-Defined, then we would choose our Apex class. Here is the resource for a variable called inputVariables

inputVariables is now the containers (like a record variable) that encapsulates our 4 variables (firstName, lastName, age, myAccount). We would access the fields using dot notation:

Make a note that when we are referring to the account we have to drill down from the the variable through the apex data type to get to the Account record and then we have access to all of the account fields. In our example we are looking at the Account name.

Now that we have the Apex data type we can populate the attributes the same way we populate record attributes in Flow. Take a look at this screen from the main flow. It has a variable defined the same as inputVariable called passVariable. I'm using the name component to assign the values to passVariable.firstName and passVariable.lastName.

I'm using an Assignment element to assign age to passVariable.age

Capturing the Account is done using the Get Records element using the resource {!passVariable.myAccount}

The values from the account that are stored are the account ID and Account Name. Using the Subflow element to pass the resources is simple. We only have to pass one variable instead of 4 variables.

Passing the single Apex defined data type gives us a simpler design

Using Apex defined data types in your Salesforce Flows allows for simpler designs because we are creating all of our common variables in one “container”, much like what Salesforce does when we use a resource variable with a datatype of record. In our example we simplified the call to the subflow by making parameter passing streamlined. Any changes to the apex data type would automatically appear in all flows that use the apex data type. The skill set to write an Apex data type is minimal and within the capabilities of all Salesforce Flow developers.

Please enjoy and share your uses cases.