Limit Access Within Your Flow Using Custom Permissions

In a previously published blog post, Why You Should Add Custom Permissions to Your #AwesomeAdmin Tool Belt, I introduced you to custom permissions. This feature has been around since Winter ’15 but remains fairly unknown and underutilized by the admin community. Awesome admins can use this superpower to lock or unlock user access to apps or processes.

In this blog post, we’ll focus on how admins can use custom permissions in Flow to either permit or deny a user from accessing a certain path in Flow.

Business problem

There has been rather high turnover at Sunshine Cupcakes, our fictional company, as of late. Devohne Mays, Operations Manager, wants to implement quality check measures for new hires to ensure they are processing the orders at the quality level that Sunshine Cupcakes has been known for. Devohne inquires with admin Addison Dogster whether all orders processed (that is, Status field value equals ‘Packaged’) by new hires can be flagged for review by the manager on shift. All other cupcake orders processed by seasoned employees would not go through this process.

The solution

Addison is happy to help Devohne with his business problem!

Cupcake orders are stored in the Cupcake Order custom object in the Sunshine Cupcakes org. To satisfy this new requirement, Addison needs to focus only on cupcake orders where the value of the Status field is set to ‘Packaged’ and the order is fulfilled by a new hire. If this scenario is true, then she will create a task and assign it to the manager on shift.

Note: Since shift managers constantly change, to simplify shift manager maintenance, Sunshine Cupcakes has decided to specify the manager on shift as a queue of managers called ‘Manager.’ The manager on shift is responsible for the queue during their shift.

Being the Flownatic that she is, Addison immediately thought about creating a record-triggered flow for her automation, as she needs the automation to fire once a record is updated that meets a certain condition. However, how would her automation know who was a new hire?

Addison is an #AwesomeAdmin and is constantly learning new tools she can use to support the business. She learned recently about a configuration feature called custom permission. This feature allows or denies user access to apps and processes. A custom permission can be assigned to a user either through a permission set or their profile. She also learned that custom permissions can be referenced in Flow. Addison can have her flow check to see if the user who updated the record has this custom permission and, if so, assign a task to the shift manager to review their order. Problem solved!

In summary, Addison’s solution comprises of:

• A custom permission
• A permission set
• A flow
• A task list view for the Manager queue

Addison first creates the custom permission. In Setup, search for ‘Custom Permissions’ in the Quick Find box. Create a new custom permission. Provide the label, name (API name), and description. The description should further describe the purpose of the custom permission and possibly where it’s used.

Addison creates the custom permission with these attributes:

• Label: Order Needs Review
• Name: Order_Needs_Review
• Description: User with this custom permission indicates their order needs to be reviewed

Next, she associates the custom permission to the permission set. In Setup, search for ‘permission sets’ in the Quick Find box.

Addison creates a new permission set with these attributes:

• Label: Order Needs Review
• API Name: Order_Needs_Review
• Description: This contains the custom permission that flags this user as needing their orders reviewed
• License (optional): You can select the specific license to use.

Then, Addison enables the custom permission by adding it to the permission set.

Now, any user she assigns to the permission set will automatically get the custom permission.

Next, Addison creates the record-triggered flow so Salesforce will automatically create a review order task for the shift manager when a new hire packages a cupcake order. (1) The record-triggered flow will start when the cupcake order record’s status is updated to ‘Packaged’. (2) Then, it will determine whether the user who updated the cupcake record needs to have their order reviewed (that is, user has the Need Order Reviewed custom permission). If yes, then (3) we will retrieve the Manager Queue Id (as #AwesomeAdmins do not hard code IDs in their flows). Lastly, (4) we create an order review task assigned to the shift manager.

Once Addison configures the flow, the end result will look like this.

In Setup, search for ‘Flow’ in the Quick Find box. Select New Flow, then select Record-Triggered Flow.

Addison wants this automation to fire when there’s a change to a Cupcake Order record only when the record is updated. A newly submitted cupcake order will never have a status of ‘Packaged’. She only wants the cupcake record to start the automation if the status is packaged (Status__c custom field equals ‘Packaged’). She only wants this to run when the cupcake record is updated to satisfy the condition requirements. Lastly, because she needs to create a task record, which is not making changes to the current cupcake order record, Addison selects to optimize the flow for Actions and Related Records.

Addison configured the Start element as follows:

• Object: Cupcake Order
• Trigger the Flow When: A record is updated
• Condition Requirements: All Conditions Are Met (AND): Status__c Equals Packaged
• When to Run the Flow for Updated Records: Only when a record is updated to meet the condition requirements
• Optimize the Flow for: Actions and Related Records

Next, she needs a way to determine whether the user who updated the record needs to have their order reviewed. This is done with a Decision Flow element, which allows you to configure conditions that must be met in order for the flow to take that given path. In Addison’s scenario, she only wants the flow to continue if the user who updated the record has the custom permission ‘Order Needs Review’.

She configures one outcome called ‘Yes’ and that ‘All Conditions Are Met (AND)’ where $Permission.Order_Needs_Review Equals True.

Custom permissions can be accessed in Flow by finding the global resource called $Permission and then selecting the custom permission API name. In this case, it’s ‘Order_Needs_Review’.

Following the path of the Yes outcome from the Decision Flow element, Addison now needs to create the order review task to assign to the Manager queue to the OwnerId field of the Task record. But remember, #AwesomeAdmins do not hard code IDs! Instead, Addison will query Salesforce to get the queue Id using the queue developer name with a Get Records Flow element.

Note: It’s best practice to query using the API or developer name, rather than the name of the component in the event the name changes. API or developer names are less likely to change than field names.

A Group record represents a set of User records. Groups can contain individual users, other groups, or the users in a particular role or territory. A Queue is a type of Group. It is a public group that includes all the User records that are members of a queue. Addison can query the Group object with a Get Records Flow element, filtering on DeveloperName Equals Manager AND Type equals Queue to get the Manager Queue Id. Once the flow finds the record, it will store all values of the Manager Queue record in memory.

Addison configured the Get Records Flow element as follows:

• Object: Group
• Condition Requirements: All Conditions Are Met (AND)
  • DeveloperName Equals Manager
  • AND Type Equals Queue
• Sort Group Records: Not Sorted
• How Many Records to Store: Only the first record
• How to Store Record Data: Automatically store all fields

Now that Addison has the Manager Queue Id, she can create the Task record by using the Create Records Flow element.

For this new task, Addison wanted to add a formatted text in the task Description field. She uses a Text Template Flow resource to help her format the text that will be displayed in the Description field. Addison can create this in one of two ways. She can create the Text Template Flow resource directly from the Manager tab or from the Value field in the Create Records Flow element. However, she needs to set up the Text Template Flow resource first.

In the Text Template Flow resource, she selects View as Plain Text so she doesn’t show HTML tags in the Description field in Salesforce — that would not be a good user experience. Then, Addison sets the body and shows the cupcake order name and the name of the user who fulfilled the cupcake order by using merge fields from the cupcake order record using the Global Variable $Record.

Addison configured the Text Template as follows:

• API Name: TaskDescriptionTextTemplate
• Description: Text for the task description
• Body:

Review Cupcake Order: {!$Record.Name} [This is the cupcake order record’s name]
Order Fulfilled By: {!$Record.Order_Fulfilled_By__r.FirstName} {!$Record.Order_Fulfilled_By__r.LastName} [This shows the name of the user who is in the Order Fulfilled By field of the cupcake order record]

Here’s a quick demo of how Addison creates the text template and references it in the Create Records Flow element.

Following on the Yes outcome path after the Get Records Flow element, next, Addison configures the Create Records Flow element. She chooses to set the record fields using separate resources and literal values, since she doesn’t already have a record with values set using an Assignment Flow element (for our configuration purpose, we’re keeping this simple).

Addison configured the Create Records element as follows:

• How Many Records to Create: One
• How to Set the Record Fields: Use separate resources, and literal values
• Object: Task
• Set Field Values for the Task:
  • Description: TaskDescriptionTextTemplate
  • OwnerId: {!Get_Manager_Queue_Id.Id} [Note: Pulls in the Id from the Get Manager Queue Id Get Records Flow element]
  • Priority: High
  • Status: Not Started
  • Subject: Please Review the Cupcake Order
  • ActivityDate: {!$Flow.CurrentDate} [Note: This looks at the Flow global variable and selects the current date of the flow]
  • WhatId: {!$Record.Id} [Note: This looks at the Id of the $Record global variable, essentially the Id of the cupcake order record that started this automation.]

Normally, Addison would debug the flow before activating it in a sandbox. However, there’s a limitation of the current record-triggered flow debugger where picklist fields are not displayed in the Edit Records section. So, Addison will need to save and activate the flow to test in her sandbox.

Addison saves her flow by calling it ‘Create a Cupcake Order Review Task’ and gives it a description: ‘Process for creating a cupcake order review task for the Shift Manager, if needed’.

Finally, she can activate her flow and test it.

She logs in as Jared Dunn, a new hire who will need their orders reviewed through this new process. She tests this as a seasoned employee who does require review to ensure all is working as expected before deploying to Production.

Lastly, Addison wants to give the shift managers a place to review the order review tasks assigned to the Manager queue. She accomplishes this by creating a list view for all task records assigned to the Manager queue.

Business results

With the implementation of this solution, Addison helped Devohne implement a quality control review process for new hires to ensure the standards customers expect from Sunshine Cupcakes are met with each order before they go out the door. The shift manager is notified each time a review is needed with a high priority task assigned to the Manager queue.

Now, it’s YOUR TURN!

Now that you know how to configure a custom permission for use in a flow, I want you to try this yourself. While the example above uses a custom permission in a record-triggered flow, custom permissions can be used in all flows (screen flows, autolaunched flows, etc.). I’m sure you have use cases where this admin superpower can come in handy. Share with us how you use custom permissions in a flow to grant or deny access to your users on Twitter using #AwesomeAdmin.

Resources

• Salesforce Security Guide: Custom Permissions
• Salesforce Admins Blog: Why You Should Avoid Hard Coding and Three Alternative Solutions
• Salesforce Admins Blog: Why You Should Add Custom Permissions to Your #AwesomeAdmin Tool Belt