I presented the contents of this blog post at Dreamforce 16 in the Developer track.

Are you an intermediate #AwesomeAdmin looking to kick your business logic skills up a notch by creating more efficient, easily maintainable processes to automate common business logic, using clicks, not code? Think outside the box and componentize your visual workflows so that the same visual workflow is called to handle common scenarios, eliminating the need to maintain several similarly constructed visual workflows.

Developers who have discovered the point-and-click power of Salesforce often find themselves looking for a more efficient, easily maintainable way to implement common business logic declaratively. Think outside the box and componentize Visual Workflow so that the same visual workflow is called to handle common scenarios, thus eliminating the need to maintain several similar visual workflows.

In this blog post, you will learn how to componentize a visual workflow so it can be re-used and how to set up process builder to pass the needed variables into the flow when automating the user administration task of assigning/removing users to/from permission sets.

Here are a few lessons learned from implementing this use case:

Create Permission Set to Extend Permissions/Access and You’re Done. Easy Peasy! Not Quite…

 

You may receive business requirements that require extending permissions or access to a subset of your users. Example, Sally Sunshine has requested that Finance Users be provided with some permissions and the Sales Division users be provided with these set of permission.

In the effort to limit the number of profiles in your Salesforce org and to provide least privilege from a security perspective to your users, you turn to permission sets to solution those requirements. These requirements can be easily fulfilled in Salesforce through configuration. Create the permission set, in this case, the ABC permission set for the Finance Department and the DEF permission set for the Sales Division users. And, assign the necessary users. Easy peasy. Done and done.

But, are you really done?  Think about what the manual maintenance of permission set assignments may cause over time especially in an org with many users. Without automation, you are relying on a human to remember to add or remove people from various permission sets. While, the chances of adding permission sets to a user being missed may be rare, especially if the user needs those permissions or access to perform his or her job, chances are much greater that the permission set removal piece will be forgotten. As system administrators or developers, it is our job to be security aware and grant users least privilege permissions, enough permissions to perform their jobs and not more to be “dangerous.” Think about situations where a Salesforce user changes roles/departments and still continues to have access where they shouldn’t. What about the case where the user had access to view encrypted data and their new role doesn’t require it, that can pose a serious security issue, especially in environments where the org stores PII or PHI data.

Automate It! Let Salesforce Do the “Remembering.”

Being the Awesome Admin/developer that you are, the solution to this is to automate user administration processes when new permission sets are created. Work with the business to find criteria or commonality among the users of the permission set, where possible, to automate the assignment/removal of permission set.

In this case, Addison built a process builder to add/remove the ABC permission set for new users where the user’s department is “Finance”, existing users whose previous department was “Finance” and or existing users whose department has changed to “Finance”  by either invoking the Add ABC Permission Set or Remove ABC Permission Set flows. She cloned the process builder and flows and adjusted them for the DEF permission set using the criteria user’s division = “Sales.”

This solution is feasible for 1, 3 or 5 permission sets. However, consider your org as it grows over time, where you have 10, 20, 50 or 50+ permission sets. 10 permission sets = 10 process builders and 20 visual workflows. This solution becomes unsustainable over time. Maintenance will become cumbersome.

Rather than create a separate visual workflows by cloning  for each permission set assignment, componentize the visual workflow (similar concept by developers when building code components) so the same visual workflow can be re-used over and over and reduce maintenance costs in your org. Process builder will send over the needed variables – action (add or remove), permission set name, process name for use in the fault email.

Yes, it will take  longer to come up with a smart, componentized design rather than creating the same process builder/flows over and over and making minor tweaks to it and delivering that to your business user. However, the amount of time you put into coming up with a smarter design, your future self or any future system admin/developer who comes behind you will thank you for it!

You can have different criteria for permission set or public group assignments in process builder, all using the same add/remove permission set visual workflow. For example, for permission set assignments:

• User belongs to Finance department, assign ABC permission set
• User belongs to Sales Division, assign to DEF permission set
• User belongs in the CSR role, assign the GHI permission set

The immediate action to invoke a componentized add/remove permission set flow would look like this:

Let me explain the variables passed from Process Builder to Visual Workflow:

• The variable varUserID will pass the user’s ID.
• The variable varPBPermissionSetAction will either specify “Add” or “Remove” to denote whether to add or remove the permission set.
• The variable varPermissionSetName is the Permission Set’s API name [Best practice: Use something less likely to change like the API Name rather than hardcode IDs. The reason why you want to avoid hardcoding SF IDs is that when a permission set is created in a sandbox, and then created in every sandbox leading up and including Production, that permission set’s SFDC ID will not be the same. You will then need to update the process builder/flow of these hardcoded IDs in every sandbox or production and hence, have different versions of the process builders/flow.]
• The variable varFlowName is the name of the visual workflow “Add/Remove User From Permission Set.”

The componentized Add/Remove Permission Set Visual Workflow looks like this:

• The first Record Lookup flow element will lookup the permission set ID using the permission set’s API name
• The Decision flow element determines whether there is a value stored in the variable for the permission set ID from the first set.
• Assuming the permission set ID variable has a value, the second Record Lookup flow element will lookup the permission set assignment using the permission set’s ID and user ID to determine if the user is already assigned to the given permission set.
• Next, the Decision flow element will determine whether the user has the permission set or not and the variable passed from Process builder as the varPBPermissionSetAction. If the action is to add the permission set and the user does not already have the permission set, it will add the permission set. If the action is the remove the permission set and the user has the permission set assigned, the flow will remove the permission set.
• The Record Create flow element will add the permission set to the user.
• The Record Delete flow element will delete the permission set from the user.
• The Send Flow Fault Email subflow element will send the fault email to the production support group.

Reduce Maintenance. Re-Use Flows With SubFlows

Ever have certain flow elements that are consistent in all your visual workflows, such as sending the fault email to production support? Rather than cause a possible maintenance issue where if you had to make a change to the flow element, you would have to touch each and every flow, you can re-use certain flow elements in every flow using the concept of a subflow.

Every flow created in the org shows up in the Flow Designer in the Palette under Flows. So, in essence, any flow in your org can be a subflow for another flow.

Once configured, all flows reference that one subflow. If you need to modify the flow actions, it is updated in one place and reflected in all flows referencing the subflow. Voila!

#MOARExamples: Process Builder & Componentized Flow

Need more examples to get those creative juices going? Here are a few…

Let’s Build It Out

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sally Sunshine is the Operations Manager. Sally wants to automate the user administration process for assigning and removing users from the various permission sets.  

• User belongs to XYZ role, assign ABC permission set
• User belongs to Finance department, assign DEF permission set
• User belongs to CSR profile, assign to GHI permission set

Solution: Being the Awesome Admin that she is, Addison is able to solve this declaratively using one process builder and two visual workflows (componentized flow and a fault email flow) to automate the assignment and removal of permission sets to users. We can do this with clicks, not code.

Quick Steps:

1.Create all the necessary permission sets. For those using Salesforce Classic, permission set can be found in Manage Users | Permission Sets. In Lightning Experience, it is found under Users | Permission Sets.

2.Create the send flow fault email flow. This is the subflow in your main visual workflow. For those using Salesforce Classic, permission set can be found in Create | Workflows & Approvals | Flows. In Lightning Experience, it is found under Process Automation | Flows.

Refer to Using Custom Metadata Type in Visual Workflow Fault Emails on how to set up the Custom Metadata Type. Now, we will set up a slight variation of the visual workflow.

A. Set up the following three variables. They will store the email and org-name values pulled from the custom metadata type data record, flow name and the fault error message passed from the main visual workflow we will create in Step 3.

Best practice tip: Provide a description so you and other/future admins know what this variable is used for.

B. Create a Record Lookup. This will lookup the custom metadata type and pull in the email recipients and org-region name in the variables created in Step 2A.

We will use MasterLabel of the Custom Metadata Type data record as the criteria.

Best practice tips:

• Provide a description so you and other/future admins know what this flow element is used for.
• Check the box next to Assign null values to the variable(s) if no records are found so your flow doesn’t fault when no records are found.

C. Next, create a send email flow element.

Configure the input tab.

Add a new row: Email Addresses (comma-separated).

Body: {!varFlowErrorMessage}

Subject: {!varOrgRegion} – ERROR: {!varCallingFlowName}

Email Addresses (comma-separated): {!varEmailAddress}

The end result looks like this…

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

D. Save as and provide the following properties.

E. Click the “Close” button.

F. On the flows screen, activate the flow.

3. Next, we will create a visual workflow to assign or remove the permission set to/from the user.  For those using Salesforce Classic, permission set can be found in Create | Workflows & Approvals | Flows. In Lightning Experience, it is found under Process Automation | Flows.

A. We will create 6 variables upfront. These will be referenced in the flow elements later on.

B. First, we will create a Record Lookup flow element called “Lookup Permission Set ID” on the PermissionSet object where the Name equals the variable “varPermissionSetName” which will be passed from the Process Builder. Once found, it will store the Id to the variable “varPermissionSetID.” We will need this value in a few flow elements.

Set this as the starting element in your flow by double-clicking on the green up arrow.

Best practice tips:

• Provide a description so you and other/future admins know what this flow element is used for.
• Check the box next to Assign null values to the variable(s) if no records are found so your flow doesn’t fault when no records are found.

The end result looks like this…

C. Create a Decision flow element called Perm “Set ID Found” that will determine that there is a value that is stored in the variable varPermissionSetID. This piece is important because the permission set ID is integral to this flow. WIthout it, the flow cannot continue.

 

Best practice tips: Provide a description so you and other/future admins know what this flow element is used for.

D. Create another Record Lookup flow element called “Lookup Permission Set Assignment” on the PermissionSetAssignment object where the AssigneeID equals the variable “varUserID” which will be passed from the Process Builder and the PermissionSetID equals the variable “varPermissionSetID” (set from the previous record lookup). We just picked a field in the PermissionSetAssignment object, AssigneeId, to set a value. If it finds a record of the user assigned to the permission set, it will set the AssigneeId (i.e user’s ID) to the variable “varUserHasPermissionSet.” If no records are found in the lookup, a null value will be stored in the variable.

Best practice tips:

• Provide a description so you and other/future admins know what this flow element is used for.
• Check the box next to Assign null values to the variable(s) if no records are found so your flow doesn’t fault when no records are found.

The end result looks like this…

E. Now we need to create a Decision flow element called “Does User have Permission Set” which determines whether the user has a permission set for the Add and Remove actions. We only want to add the permission set if the user does not already have the permission set and remove the permission set if the user already has the permission set. If we do not put this decision in our flow, it will fault because it would result in a duplicate permission set assignment or the system will try to remove a permission set that does not exist for the user.

The decision outcome “Add Process Builder Path – No Permission Set” is the {!varUserHasPermissionSet} is null {!$GlobalConstant.True} AND {!varPBPermissionSetAction} equals Add.

The decision outcome “Remove Process Builder Path – No Permission Set” is   the {!varUserHasPermissionSet} is null {!$GlobalConstant.False} AND {!varPBPermissionSetAction} equals Remove.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

The end result looks like this…

F. Create a Record Create flow element called “Add User to the Permission Set” on the PermissionSetAssignment object and set the field AssigneeId with the variable “varUserID” and the PermissionSetId with the variable “varPermissionSetID.”

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

The end result looks like this…

G. Now, we will create a Record Delete flow element called “Remove Permission Set From User Record” for the PermissionSetAssignment object where we will delete the record that meets the following criteria: AssigneeId equals the variable “varUserID” and PermissionSetId equals variable “varPermissionSetID.”

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

The end result looks like this…

H. Bring in the Send Flow Fault Email flow under the Flows listing in the palette.

Let’s give our subflow the same name and description as the original flow.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

In the Inputs tab, add the following:

• varCallingFlowName: {!FlowName}
• varFlowErrorMessage: {!Flow.FaultMessage}

In the Outputs tab, you will see a blank row for the source/target. Click the trashcan icon to delete the output row. This is not needed.

The end result looks like this…

I. Now, you need to connect the flow elements to match the below…

Can’t seem to get the fault connector to appear? Create a temporary flow element (circled below), draw your first connector to that temporary flow element. Then, draw another connector to the send element. This connector has the word “FAULT” in it.  

Once that is completed, delete the temporary flow element you created. This is the end result.

J. Save as and provide the following properties.

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

K. Click the “Close” button.

L. On the flows screen, activate the flow.

4. Lastly, let’s create the process builder. For those using Salesforce Classic, permission set can be found in Create | Workflows & Approvals | Process Builder. In Lightning Experience, it is found under Process Automation | Process Builder.

Call the Process Builder “Add/Remove Permission Set,” provide a description and click the “Save” button.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this process builder is used for.

• User belongs to Finance department, assign ABC permission set
• User belongs to Sales Division, assign to DEF permission set

 

A. Select “User” as the object. Select to start the process “when a record is created or edited” and click the “Save” button.

B. While I showed, for illustration purposes, one process builder that has several criteria nodes to cover different permission sets that can be assigned, I will explain three criteria in detail.

First Criteria: New User w/ Finance Department

This will assign the ABC permission set if there is a new user user who has a department equals to “Finance.”

Since we cannot use the picker to select the criteria where the record is new, we will need to use “Formula evaluates to true” for the Criteria for Executing Actions*

This is the syntax to paste in the formula field:

ISNEW() && [User].Department = “Finance”

Immediate Action:

• Action Type: Flows
• Action Name: InvokeFlowAddPermSet
• Flow Name: Add_Remove_Permission_Set
• Flow Variables:
  • varUserID reference [User].Id
  • varPBPermissionSetAction String Add
  • varPermissionSetName String ABC_PermissionSet
  • varFlowName String Add/Remove User from Permission Set

The end result looks like this…

Second Criteria: Existing User Previously Finance Department

This will remove the ABC permission set if  the existing user previously had the department equals to “Finance.”

Since we cannot use the picker to select the criteria using the priorvalue syntax, we will need to use “Formula evaluates to true” for the Criteria for Executing Actions*

This is the syntax to paste in the formula field:

[User].IsActive && PRIORVALUE([User].Department)=”Finance” &&
ISCHANGED([User].Department)

Immediate Action:

• Action Type: Flows
• Action Name: InvokeFlowRemovePermSet
• Flow Name: Add_Remove_Permission_Set
• Flow Variables:
  • varUserID reference [User].Id
  • varPBPermissionSetAction String Remove
  • varPermissionSetName String ABC_PermissionSet
  • varFlowName String Add/Remove User from Permission Set

The end result looks like this…

Here is the criteria node/immediate actions for the new sales division user for the DEF permission set.

This should give you a sense of what to do with the criteria and immediate actions.

C. Go back to the Stop actions at the end of each node and set it to “Evaluate the Next Criteria” and click the Save button. This is a Summer 16 enhancement. Repeat this for all steps except the last step.

D. Now, you are ready to activate your process builder. Click on the “Activate” button.

That’s it! Congrats! You’ve implemented a process to automate the assignment of permission sets.

Now, before you deploy the changes to Production, don’t forget to test your configuration changes.

Deployment Notes/Tips:

• Permission sets, process builder and visual workflows can be deployed to Production in a change set (or can be deployed using a tool such as Dreamfactory’s Snapshot).
• Activate the process builder and two visual workflows as they are deployed as inactive into Production.

As you configure your own process builder/flow and run into issues, post to the success community for help:

• Salesforce Process Builder
• Salesforce Workflow Automation
• Visual Workflow Discussions
• Salesforce Automation Hour