Make the Most of Global Variables and Values

Learning Objectives

After completing this unit, you’ll be able to:

• Reference the running user’s fields in Flow Builder.
  
• Reference the running user’s role and profile information in Flow Builder.
  
• Reference custom labels in Flow Builder.
  
• Reference custom metadata in Flow Builder.
  

This badge is one stop along the way to Flow Builder proficiency. From start to finish, the Build Flows with Flow Builder trail guides you through learning all about Flow Builder. Follow this recommended sequence of badges to build strong process automation skills and become a Flow Builder expert.

What Is a Global Variable?

Global variables exist in every flow. You don’t create them and you can’t change their values in the flow, but they give your flow access to very useful data that can be different each time the flow runs.

You can use global variables in fields that let you select a resource. Such fields usually contain placeholder text such as “Enter value or search resources…” or “Insert a resource…” 

In Flow Builder, global variables behave similarly to objects and fields: each global variable contains multiple values. To use a global variable in a flow, follow these steps.

1. While creating or editing an element, click in a field that lets you select a resource. Flow Builder displays the resources you can place in this field.
   
2. Under Global Variables, select a variable that starts with $. Flow Builder displays the fields available to the selected variable.
   

In some elements, the global variables have different names and don’t start with $. However, they’re still located in the field’s Global Variables section. The Flow Builder development teams are currently updating each element to use these new names. Until that process is complete, we’ll provide both names for each global variable we discuss.

3. Select the field that holds the value that you want to use.
   
   

Keep in mind that the global variable field’s data type must be compatible with the data type of the field. For example, to set the default value of a date/time field, you must select a date or date/time global variable field. Or to set the value of a currency field, you must select a number or currency global variable field.

Get the Running User’s Field Values

The $User global variable (or, in some elements, the Running User global variable) gives your flow a glimpse at the user behind the keyboard. We don’t mean that literally, of course. But it does give your flow access to the user data of the user that runs your flow. Use the $User global variable to access data like the running user’s ID, name, manager ID, email address, and much more.

Pyroclastic’s sales managers want to know when a team member closes a high-value opportunity as lost. Flo asks you to automate that notification with a Chatter post to the opportunity owner's manager. The person closing the opportunity might not be the opportunity’s owner, so the notification should indicate who made the change.

You already have a flow that runs when the StageName of an opportunity changes to Closed Lost: Create Follow-Up with Decision Maker. Add an action in that flow to make a Chatter post to the opportunity owner’s manager.

First, you need to identify the owner’s manager. As you did in unit 2, use a Get Records element to retrieve information and then use that information in an Action element.

Retrieve the Owner’s Manager

1. Open the Create Follow-Up with Decision Maker flow.
   
2. On the flow canvas, after the Get Decision Maker element, click . Select Get Records.
   
3. For Label, enter Get Owner Manager.
   Remember, this name is used to label the generated variable, so it’s a good idea to use a descriptive name.
   
4. For Object, select User.
   
5. For Condition Requirements, select All Conditions Are Met (AND).
   
6. In the Filter Records section, define conditions that tell the element which records to retrieve:
   

• Field: Id
  
• Operator: Equals
  
• Value: $Record > Owner > ManagerId
  

7. Click  in the New Get Records panel to close the panel.
   

You now have a record variable that contains all the fields from the opportunity owner’s manager, including their name and email address. Next, you use an Action element to create the Chatter post.

Create a Text Template

1. In Flow Builder, if the Toolbox isn’t already open, click to open it.
   
2. Click New Resource.
   
3. For Resource Type, select Text Template.
   
4. For API Name, enter ChatterPostManager.
   
5. Next to the Resource Picker field, change View as Rich Text to View as Plain Text.
   
6. In the Resource Picker field, select User from Get_Owner_Manager > Id.
   A merge field for the manager’s name is inserted at the beginning of the message body.
   
7. Add square brackets [ ] around the merge field, like this:
   [{Get_Owner_Manager.Id}]
8. Add an @ symbol at the beginning and a colon at the end, like this:
   @[{Get_Owner_Manager.Id}]:
   

Remember, when followed by a value enclosed in square brackets, the @ symbol inserts the value as a mention in the Chatter post.

9. After the colon, start a new line and enter:
   

   This opportunity was marked Closed Lost.
   Closed by:

10. Leave a space and then insert three more merge fields using the $User global variable, found in the Global Variables section. Make sure to add a space between them so they don’t run together:
    

• $User > FirstName
  
• $User > LastName
  
• $User > Email
  
  [Alt text: The New Resource window corresponding to the previous steps.]
  

11. Click Done.
    

Next, you use the text template in an Action element to post to the opportunity’s Chatter feed.

Notify the Manager in a Chatter Post

1. After the Get Owner Manager element, click . Enter post in the Search bar.
   
2. Select Post to Chatter.
   
3. For Label, enter Chatter Post to Manager.
   
4. For Message, select the ChatterPostManager text template.
   
5. For Target Name or ID, select Triggering Opportunity > Owner ID.
   
6. Click Done.
   
7. Save the flow.
   

Get the Running User’s Profile and Role Values

When creating flows, avoid hardcoding IDs. Hardcoding is when you manually enter a Salesforce ID into flows or code. An example of hardcoding in an Update Records element is setting criteria to check for “005i000006rZRFU”. Instead, you should retrieve the ID with a Get Records element, and check the ID that’s stored in the Get Records element’s record variable.

Why should you avoid hardcoding? Salesforce IDs can change at any time. If you build a flow with a hardcoded ID in a sandbox, it’s likely that the record you’re trying to reference has a different ID in other sandboxes and in production. Also, it’s difficult to understand or troubleshoot a flow when you can’t easily see which record an ID represents.

What does this have to do with global variables? At some point, you might want to access the user’s profile or role. Suppose your organization is divided into territories, assigned as user roles to salespeople. The Western territories (Sales-West1, Sales-West2, and Sales-West3) use a different discount calculation than other territories. To calculate discounts correctly, a flow needs to get the running user’s role to confirm whether they’re assigned to one of the Western territories.

Flo tries to use the $User global variable to find the running user’s role, but the only role value there is the role’s ID. She knows better than to hardcode an ID in her flow. Fortunately, there’s another way to access information from the running user’s role: the $UserRole global variable (or, in some elements, the Running User Role global variable). It can access many values in the running user’s role.

Likewise, the $Profile global variable (or, in some elements, the Running User Profile global variable) should be used in similar situations where the flow needs to access the running user's profile values. The only profile value in $User is the profile's ID, but just like $UserRole for roles, $Profile grants access to the rest of the profile's values.

To avoid hardcoding when checking the running user’s role, reference $UserRole > DeveloperName. For profile, reference $Profile > Name.

After finding out that the user is assigned to a Western territory, Flo uses a Decision element so that the flow can apply the Western territory discount instead of the standard discount used by other territories. You learn about the Decision element in Flow Builder Logic, the badge just ahead of this one on the Build Flows with Flow Builder trail, so you don’t have to jump ahead; you can just finish this badge first.

Retrieve Custom Labels

If your organization’s users work in multiple languages, custom labels are very valuable. Custom labels contain a string of text that you can translate into multiple languages. After you define the translations, Salesforce displays custom labels to each user in the user’s native language. You can even use custom labels in flows.

In Flow Builder, use the $Label global variable (or, in some elements, the Custom Label global variable) to place a custom label anywhere that accepts a text resource, such as screen components, default values for fields, and text formulas. In this example, creating a task record, the value of the Subject field is set to the TaskPrintLabels global variable. Now when users view the task, its subject is in their own language.

The next example is a Display Text component on a flow screen. In the Resource Picker field, when $Label is selected, available custom labels are listed. Selecting one adds it to the text area in the component.

Other Important Global Variables

There are a few other global variables that can be useful when creating flows.

Retrieve Custom Metadata Values

Custom metadata isn’t a global variable, but it is a set of values that you can access globally: in Flow Builder and throughout your Salesforce org. For example, a custom metadata type can be used across flows, code, validation rules, and more.

In Flow Builder, you retrieve custom metadata in the same way you retrieve object records: using the Get Records element. When selecting the object, select the custom metadata type.

Looking for your custom metadata types? Look for the items with an API name that has __mdt at the end.

For more information and sample use cases, check out the Custom Metadata Types Basics Trailhead module, particularly the Using Custom Metadata Types in Flow unit.

Resources

• Salesforce Admins Blog: Why You Should Avoid Hard Coding and Three Alternative Solutions
• Salesforce Admins Automate This! Video: Automate This! — Send Case Notifications Automagically with Flow
• Trailhead: Custom Metadata Types Basics