Grant Flow Permissions and Context

Learning Objectives

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

• Grant users permission to run flows.
  
• Update permission sets to provide access required by your flows.
  
• Identify the default and optional contexts in which a flow runs.
  

The previous badge, Flow Implementation I, is required (so that you can reuse its playground). You need the package installed and we don't cover that installation in this badge.

Let’s face it: Flows can be complex. They can contain a lot of moving parts and interact with nearly every aspect of Salesforce in some way. Even the simplest of flows can cause an error if it’s not designed with the rest of Salesforce in mind. Let’s talk about some common problems that your flows can encounter.

Give Users Permission to Flow

Deploying a flow in a place where your users can access it doesn’t necessarily mean those users can run the flow. To run flows, a user needs one of these permissions.

• The Flow User permission on their user record.
  
• The Run Flows permission on an assigned profile or permission set
  

The Run Flows system permission lets users run active flows. Only admins with the Manage Flow user permission can run inactive flows.

These permissions allow users to run any flow that isn’t restricted. It’s more efficient to grant access to groups of people through a profile or permission set.

Ready to get hands-on with Flow Builder?

Launch your Trailhead Playground now to follow along and try out the steps in this module. To open your Trailhead Playground, scroll down to the hands-on challenge and click Launch. You also use the playground when it's time to complete the hands-on challenges.

Let’s enable the Run Flows permission on a permission set.

1. In Setup, enter permission in the Quick Find box, and select Permission Sets.
   
2. Select Pyroclastic Support.
   
3. Select App Permissions.
   
4. Click Edit.
   
5. In the Flow and Flow Orchestration section, select Run Flows.
   
   
6. Click Save.
   
7. Click Save again.
   

Now all users with the Pyroclastic Support permission set can run any unrestricted flow they find.

After giving users permission to run every flow, you may want to restrict access to certain flows. The Principle of Least Privilege is a keystone of information security: Give a user only what they need to do their job, and nothing more. For more information on restricting flow access, check out Limit User Access to Execute Flows in Salesforce Help.

Give Users the Permissions Their Flows Need

When creating a flow, it’s easy to get caught up in what the flow should do: Get this record, update that record, send those emails. But it’s important to remember that Salesforce permissions still apply. If a user runs a screen flow that creates an opportunity but that user doesn’t have a profile or permission set that allows them to create opportunities, the flow will fail.

Let’s look at another flow plan.

All support users need to run this flow. The flow creates cases and sets relevant case fields. Therefore, all support users need the ability to create cases and edit relevant case fields. Support users all have the Pyroclastic Support permission set (which is brand new and still has a few problems) so let’s make sure that permission set has everything it needs.

1. On the Pyroclastic Support permission set, select Object Settings.
   
2. Select Cases.
   
3. Click Edit.
   
4. In the Object Permissions section, select Create and Edit on the Cases line.
   

Don’t save just yet. First, let’s make sure this permission set can access all the relevant case fields.

1. Scroll to the Field Permissions section.
   Take a look at the permissions that this permission set has for each field on the Case object. The permission set has edit access to most of the flow’s relevant case fields, but it needs edit access to the QA Reviewer field.
   
2. In the QA Reviewer row, select Edit Access.
   When you select Edit Access, Read Access is automatically selected.
   
   
3. Click Save.
   

The Pyroclastic Support permission set now has access to edit all the relevant case fields touched by the Create Case for Contact flow. Without that access, users would receive an error message when the flow tries to create a case with data in the field that they don’t have permission for.

Know a Flow’s Context

Screen flows often require object and field access, but not all flows require that kind of access. For example, record-triggered flows don’t worry about users’ permissions. This is because screen flows and record-triggered flows operate with different contexts.

Context is another concept found in all types of development. Simply put, context is a definition of who is running the automation. For flows, there are three types of context.

Let’s focus on the difference between “with Sharing” and “without Sharing” for a moment. “Sharing” refers to the record sharing defined by sharing settings such as organization-wide defaults, sharing rules, and manual shares. For example, if a user has Read access for cases, but the org-wide default for the Case object is set to Private, their Read access is limited to the cases they own.

So when talking about contexts, “with Sharing” means these sharing settings are in full effect, and “without Sharing” means sharing settings are ignored. Therefore, System Context without Sharing grants nearly unlimited access. That can be a good thing or a bad thing! For example, it can be good to have a flow that checks for open opportunities on the same account when a case is updated, so you don’t need to give everyone access to opportunities. But it can be bad to have a flow that allows users to view secure, personal contact details, especially if users who shouldn’t access those details have access to that flow.

For flows, the flow type determines the default context of the flow. However, some flow types allow you to change the context. Let’s look at the possibilities.

This discussion of contexts is simplified to give you the basics of how contexts usually work in the most common flows. There are other flow types and ways to run flows that have their own contexts, and there are many exceptions where contexts change or behave differently. For more detailed information, check out Your Guide to Determining the Flow Running User and Its Execution Context in the Salesforce Admins blog.

You learn more about changing a flow’s context in the next unit.

Resources

• Salesforce Help: Limit User Access to Execute Flows
  
• Salesforce Help: Sharing Settings
  
• Salesforce Admins Blog: Your Guide to Determining the Flow Running User and Its Execution Context