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

• Automate the removal of a deactivated user from groups and queues.
• Understand the object structure for public groups and queues and the users/groups assigned to them.
• Use process builder to invoke flow.
• Strengthen your flow from faulting by adding decision elements.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes providing the purpose of a process builder, flow, variable, etc.

When a user is deactivated, there is work needed to clean up the org of references to this user. When I look at a group or queue, I only want to see active users. Seeing inactive users is just clutter to me. And if you accumulate deactivated users over time, then it becomes a bigger chore to clean them up manually. When a user is deactivated, it would be great to just remove the user from everything. This may be difficult from a reports perspective since you would want to physically replace the deactivated user with a new one, but for things like public groups, queues or anything the user is a member of and not the sole person assigned, just remove the users for me.

Now, with powerful automation tools like process builder and visual workflow, automating things like this is now feasible using clicks, not code! Hooray!

Before moving forward, let me explain the overall structure for public groups and queues. The overall setup for public groups and queues is stored an object called Groups with another object called GroupMembers that holds the users or group that are associated to a public group or queue.

We will use process builder to execute the process when a change is made on a user record. We need to use flow because process builder cannot delete records, but flow can.

P.S. If your org has paid managed packages with user package licenses, refer to my previously published blog post on automating the removal of managed package user licenses for a deactivated user.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Addison noticed when performing a user audit review, that although user are deactivated in Salesforce, the users are still assigned to public groups and queues. Although the removal of a user from their associated groups and queues are on the checklist activity, sometimes, it may be overlooked due to human error. 

Solution: While this can be handled via a trigger, Addison Dogster, being the Awesome Admin that she is, is able to solve this using process builder and visual workflow. She can do this with clicks, no code!

Quick Steps:

1.Let’s create the visual workflow (Create | Workflows & Approvals | Flows in Salesforce Classic or Process Automation | Flows in Lightning Experience).

This flow will lookup and see if the user is associated to any public groups or queues, then it will determine is any records were found, and if yes, then delete the associations.

A. We will create 1 variable upfront, which will store the user ID.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what these variables are used for.

B. Create 1 SObject Collection Variables, to hold the collection of the user associated public groups and queues.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what these sobject collection variables are used for.

C. Perform a Fast Lookup flow element that will lookup the GroupMember object where the UserId is the user ID passed from process builder. Once it finds GroupMember records, it will store it in the sObject collection variable sCollectionofUserGroupsQueues.

Check the box “Assign null to the variable if no records are found.”

Then specify to save the GroupId as the record field in the variable.

The end result should look like this…

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

D. Now, we need to use a Decision flow element to determine whether records were found in the Fast Lookup to continue on with the process.

We want to decide whether the sobject collection sCollectionofUserGroupsQueues has records so it is set to {!sCollectionofUserGroupsQueues} is null {!GlobalConstant.False}, which means that the sobject collection is not null.

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

 

E. We now need a Fast Delete flow element to delete the records found in the sobject collection sCollectionofUserGroupsQueues.

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

F. Draw the other connectors between the flow elements.

G. Add the subflow Send Flow Fault Email. For instructions on how to create this, go to Step 2 of blog post: Maximize Maintainability With Process Builder and Componentized Visual Workflow.

H. Set your flow starting point. And connect the flow elements and the fault connectors 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.

I. Click on the Save button and provide the following information

Best Practice Tip: Don’t forget to provide a description so you and other/future admins know what this visual workflow is for.

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

J. Click the “Close” button.

K. On the flows screen, activate the flow.

2. Finally, we will create a process using process builder that will run when a user is deactivated and will invoke the flow created in Step 1. Create a process builder (Create | Workflows & Approvals | Process Builder in Salesforce Classic or Process Automation | Process Builder in Lightning Experience).

Note: The screenshot shows one additional immediate action. The first action step was to invoke the user removal from managed package licenses and associated permission sets. Refer to my previously published blog post on automating the removal of managed package user licenses for a deactivated user.

A. Set the process builder properties. We will call this process “Deactivate Users”, provide it a description and select this process to start when “A record changes.”

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

B. We need to select “User” as the object and we want our process to run when a record is created or edited, click the “Save” button.

C. We need to specify the criteria node that needs to be met to then execute the flow. Let’s call out criteria “User is deactivated” which will execute when “conditions are met.”

We want this to run when the user’s active field has changed and the active field is set to false. Save the criteria node.

D. Next, we want to set the immediate action to invoke the flow we created in Step 2.

Action Type: Flows

Action Name: InvokeFlowRemovePublicGroupsQueues

Flow: Remove User from Public Groups and Queues (this was the flow we activated in Step 1)

Set Flow Variables: We want to send the User’s ID in the variable varUserID.

The end result looks like this…

E. Click on the “Activate” button to activate the process.

Congrats, you made it to the end! You’ve implemented a process to automatically remove the user from public groups and/or queues when a user is deactivated.

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

1. Assign a user to a group.
   • Confirm that the user is assigned to a group.
2. Go to the user record, deactivate the user and save.
   • Confirm the user’s active field is unchecked.
   • Navigate to the group.
   • Confirm that the user is no longer listed as member of the group.
3. Assign a user to a queue.
   • Confirm that the user is assigned to the queue.
4. Go to the user record, deactivate the user and save.
   • Confirm the user’s active field is unchecked.
   • Navigate to the queue
   • Confirm the user is no longer associated to the queue.

 

Deployment Notes/Tips:

• The process builder and visual workflow can be deployed to Production in a change set (or can be deployed using a tool such as Dreamfactory’s Snapshot).
• You will find the process builder and visual workflow components in a change set under the Flow Definition component type.
• Activate the process builder and visual workflow as they are deployed as inactive into Production.