Do you run reports every quarter or X number of days to see the which users have logged in since? Then, go through the manual task or use Data Loader to deactivate those users? What if, you didn’t have to lift a finger and Salesforce can just auto-deactivate these users for you? Sounds good? It’s possible with automation, done through configuration.

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

• Learn how to configure a scheduled flow.
• Learn how to invoke flow from process builder.
• Learn how to use a custom metadata type to manage app configuration or text and avoid “hardcoding” this in our processes and flows.
• Learn how you can use community built flow actions – in this post, we will use the Send Rich Email (Send HTML Email Action) – to enhance the power of flow from UnofficialSF.
• 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 variables, the purpose of a flow, what each flow element does, etc.

Business Use Case:  Addison Dogster is the system administrator at Universal Containers. Part of her job is user maintenance and ensuring that people who are using Salesforce have the access they need. She noticed that there were several users in her org whom have never logged in or has not logged into Salesforce in over 90 days. She cleaned up those users and deactivated them but she didn’t want to have to do this every 90 days. Can Salesforce deactivate the users for her? YES!

Solution: Addison figured she can configure a scheduled flow to run every day that runs through the users, but she didn’t want it to go through all the users. However, she didn’t want this to run for all users every day. Ideally, this would only run for active users whose last login date is over 90 days OR never logged in at all.

Unfortunately, in a schedule flow, you cannot set a relative date on the record filter. Bummer!

Addison thought, I can create a formula on the user object that calculates the days since last login to greater than 90.

Nope. Last Login Date field is not available in formulas. Doh!

Addison knows that in Flow, she can have a decision to evaluate the length of time since last login and then decide whether to take action.

Addison has a list of the profiles that this process would apply to (not to System Administrators, Integration Profiles or Community users, for example), BUT she also did not want to maintain the list of profiles (i.e. hardcode) in the flow schedule record filter. If she needed to add a new or remove a profile or two, she wanted to be able to do this in a pinch WITHOUT having to touch the flow.

She’s going to manage the list of profiles opting into this auto-deactivation via custom metadata type (CMDT), which she can add and remove profile records. There is no impact to the the flow. Great!

Addison did not want to catch the users off guard and just deactivate their accounts. She will notify them and their manager a week in advance that is the user did not log in, they will be subject to the deactivation policy and will be deactivated in a week. This way, is the user still wants access, all they needed to do was log in.

Solution includes:

• Two custom fields on the user object. One to track the user’s actual profile name, not just the associated profile (profileId) and another to flag the user as qualifying for the auto-deactivation.
• Two custom metadata types: One to contain the profiles for auto-deactivation and another to hold the warning and deactivation thresholds
• A process and flow to specify or not specify that a user qualifies for auto-deactivation (per their associated profile) for any new user, user whose profile has changed or a user who is reactivated.
• A flow that evaluates the last login against the warning and deactivation thresholds and notifies the user and their manager of pending deactivation with continued login inactivity or deactivates the user account and notifies the user and their manager of the deactivation activity.

View image full screen

What, what is a custom metadata type? Read the section called “What’s a custom metadata type?” in this previous blog post.

Steps: 

1.Create a new formula field on the User object called “Profile Name.” The formula syntax to use is Profile.Name. We will use this field to do the lookup against the custom metadata type of profiles that will use the auto-deactivation.

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

2. Create another custom field on the User object. This time, we will create a checkbox field called “Qualifies for Auto-Deactivation.” We will set this to true on the user record for anyone associated to a profile that is subject to the auto-deactivation. This is one of the record filters used in the scheduled flow.

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

3. Create the Custom Metadata Type. This CMDT will store text, checkbox or numeric values that are references in code, flow, process or validation rules, which can be maintained in one place. In Classic, go to Setup | Develop | Custom Metadata Types | New or in Lightning, go to Setup | Custom Code | Custom Metadata Type | New. Let’s call this “Generic Configurable Reference.”

View image full screen

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

A. Create one custom text field called Text Data, one Checkbox field called Checkbox Data and one numeric field called Numeric Data.

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

B. Create two custom metadata type records, one called AutoDeactivationThreshold to hold the number of days since login for deactivation and another called AutoDeactivationWarningThreshold to hold the number of days since login for the warning. Example below.

View Image Full Screen

4. Create another the Custom Metadata Type. In Classic, go to Setup | Develop | Custom Metadata Types | New or in Lightning, go to Setup | Custom Code | Custom Metadata Type | New. Let’s call this “Profiles for Auto-Deactivation.”

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

A. Create one custom text field called Profile Name and this will hold the profile name you want to use the auto-deactivation process.

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

B. Create a custom metadata type record for each profile that will be subject to the auto-deactivation. Example below.

5. Let’s create the flow that will be invoked from a process. This will lookup the user’s profile against the Custom Metadata Type and if found, it will set the checkbox Qualifies for Auto-Deactivation to true. If the profile is not found, it will uncheck the Qualifies for Auto-Deactivation checkbox so it will not be picked up for the daily auto-deactivation process. 

For those using Salesforce Classic, flow can be found in Create | Workflows & Approvals | Flows. In Lightning Experience, it is found under Process Automation | Flows. Click on “New Flow.” Select Autolaunched Flow. Click on the Create button.

A. Let’s create our flow resources. Go to the Manager tab, click on the New Resource button.

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

Let’s create a text variable called “varUserId” that will store the userId of the user who may or may not qualify for auto-deactivation.

• • Resource Type: Variable
  • API: varUserId (I like starting any variables with “varXXXX”)
  • Data Type: Text
  • Availability Outside the Flow:Available for input: checked (This will allow a process to send a value into this variable)
  • Available for output: unchecked

Your completed variable should look like this.

Create another text variable called “varProfileCMDTRecord” that will store a value if the CMDT record for the profile is found. If the variable is null, this means no profile CMDT record was found.

• • Resource Type: Variable
  • API: varProfileCMDTRecord (I like starting any variables with “varXXXX”)
  • Data Type: Text

Your completed variable should look like this.

Create our last text variable called “varProfileName.” If there is a value, this means the user is already assigned to the permission set group. If the variable is null, this means that the user is not already assigned to the permission set group.

• • Resource Type: Variable
  • API: varProfileName (I like starting any variables with “varXXXX”)
  • Data Type: Text

Your completed variable should look like this.

Now, let’s create a formula variable called “QualifiesForAutoDeactivationFieldFormula.” If the {!varProfileCMDTRecord} is blank, then set the value to false (i.e. user does not qualify for auto-deactivation), otherwise, set it to true (i.e. user does qualifies for auto-deactivation).

• • Resource Type: Formula
  • API: QualifiesForAutoDeactivationFieldFormula (I like end my formulas with “XXXXFormula”)
  • Data Type: Boolean
  • Formula: If (ISBLANK({!varProfileCMDTRecord}), false, true)

Your completed variable should look like this.

B. First, drag the Get Records flow element to the canvas so we can query the Custom Metadata Type Profiles for Auto-Deactivation object for the user’s associated profile.

• • Label: Look up the CMDT for Profiles for Auto-Deactivation
  • Object: Profiles for Auto-Deactivation
  • Filter the Auto-Deactivation Records by Profile_Name__c Equals {!varProfileName}.
  • How Many Records to Store: Only the first record
  • For the “How to Store the Data” option, I chose to use “Choose fields and assign variables (advanced)” because I only care about one field but you can use the first two options as well. It’s just a preference thing in this case.
  • Where to Store Field Values: In separate variables
  • Select Variables to Store Auto-Deactivation Fields: Id to {!varProfileCMDTRecord}
  • When no records are returned, set specified variables to null: Checked

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

Your completed Get Records flow element looks like this.

View image full screen

C. Drag an Update Records flow element to the canvas so we can update the Qualifies_for_Auto_Deactivation__c field on the user record to true, if the user’s profile was found in the Custom Metadata Type object in the previous step, or false, if the profile was not found

• • Label: Update the Qualifies for Auto-Deactivation Field
  • Object: User
  • Filter the User Records that meet these conditions:
  • Qualifies_for_Auto_Deactivation__c: {!QualifiesForAutoDeactivationFieldFormula}

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

Your completed Update Records flow element looks like this.

View image full screen

D. 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.

E. Connect the flow elements and fault connectors to match the below…

F. Save/Save As and provide the following properties.

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

G. Before you activate your flow, test this by using the Debug button. After you are building this in a Summer ’20 or higher instance, check the Enable rollback mode checkbox so you don’t inadvertently update records while debugging. You will provide two inputs: varProfileName (name of the profile for the user) and varUserId (the id of the user). Click Run.

Note for Spring 20 orgs: Only use the Debug feature in a sandbox as it will update records. Because of this, NEVER use the flow debug function in Production.

H. Click the “Activate” button.

6. Now, we need to create a process for a new user, any user whose had a profile change or has been re-activated, we want to invoke the flow we created in Step 5 to set the Qualifies for Auto-Deactivation field accordingly.

Create a process using process builder (Create | Workflows & Approvals | Process Builder in Salesforce Classic or Process Automation | Process Builder in Lightning Experience).

A. Set the process builder properties. We will call this process “Take Action on New/Existing User”, provide it a description and select the 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.

C. We need to specify the criteria node that needs to be met to then execute the flow. Let’s call out criteria “New | Profile Changed | User Activated” which will execute when the “Formula evaluates to true” where the user is new, the profile is changed or the user’s active field was changed and the user was activated.

Formula:

ISNEW() ||
ISCHANGED([User].ProfileId ) ||
(ISCHANGED([User].IsActive) && [User].IsActive = True)

Note: We needed to use a formula because we can’t use the IsNew() syntax in the condition builder.

View image full screen

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

Set the immediate action to the below.

• • Action Type: Flows
  • Action Name: Invoke Flow
  • Update the Qualifies for Auto Deactivation Field
  • Set the flow variables to the following:
    • varUserId Field Reference [User].Id
    • varProfileName Field Reference [User].Profile_Name__c

Save the immediate action.

The end result looks like this…

View image full screen

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

7. Install the Send Rich Email (Send HTML Email Action) from UnofficialSF. We want to send a HTML rich text email via flow and also want to copy the manager. Both are current limitations in flow. Thank goodness for this component. We will use this component in out next step.

I highly recommend installing and testing this in a sandbox first. Don’t just install it directly to Production. To ensure you are installing in a sandbox, always make sure the URL is test.salesforce.com.

Example below:

• Sandbox installation: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t3h000002Ne4QAAS
• Production installation: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t3h000002Ne4QAAS

8. Now, we need to build the scheduled flow that will run daily that will look through all the user records that are active and have the Qualifies for Auto Deactivation checkbox set to true.

(A) It will look up the warning and deactivation threshold from two Custom Metadata Type records created in Step 3.

(B) Next, it will determine whether based on the user’s last login date, whether they have exceeded the warning threshold. It also takes into account if a user have never logged in, whether the created date exceeded the warning threshold.

(C) If it is exceeded, then we look up the manager’s email.

Note: this process assumes all user records has a manager. If not, you need to build in a decision to determine whether the user has a manager or not. If the user has a manager, then lookup the manager’s email. If not, skip the step.

(D) Then, there is another decision to determine whether the days since login or days since creation (if there is no login) are under the deactivation threshold or not.

(E) If we are in the warning threshold, we will send the user and their manager an email informing them of the pending deactivation if no action is taken. This is done using a custom built action to send HTML emails from UnofficialSF.

(F) If the deactivation threshold is met, we will deactivate the user.

G) And lastly, send an email to the user and their manager that their account has been deactivated.

View image full screen

For those using Salesforce Classic, flow can be found in Create | Workflows & Approvals | Flows. In Lightning Experience, it is found under Process Automation | Flows. Click on “New Flow.” Select Scheduled Flow. Click on the Create button.

A. Let’s set the schedule. Provide the start date and a start time in the future. Then select the frequency (daily or weekly).

B. Next, set the object you want the flow to run on. 

• • Object: User
  • Condition Requirements: Conditions are MET (AND)
  • IsActive Equals {!GlobalConstant.True}
  • Qualifies_for_Auto_Deactivation__c Equals {!GlobalConstant.True}

Configure it as follows:

C. Let’s create our flow resources. Go to the Manager tab, click on the New Resource button.

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

Let’s create a formula variable called “DaysSinceLoginFormula” that will calculate the days since last login. Note: The $Record is a global variable representing the user record being processed in the scheduled flow.

• • Resource Type: Formula
  • API: DaysSinceLoginFormula (I like ending any formulas with “XXXXFormula”)
  • Data Type: Number
  • Decimal Places: 0
  • Formula: Today()-DATEVALUE({!$Record.LastLoginDate})

Your completed variable should look like this.

View image full screen

Let’s create another formula variable called “DaysSinceCreationFormula” that will calculate the days since user creation.

• • Resource Type: Formula
  • API: DaysSinceCreationFormula (I like ending any formulas with “XXXXFormula”)
  • Data Type: Number
  • Decimal Places: 0
  • Formula: Today()-DATEVALUE({!$Record.CreatedDate})

Your completed variable should look like this.

View image full screen

D. Drag the Get Records flow element to the canvas so that we can lookup the Generic Configurable Reference Custom Metadata Type to get the warning deactivation threshold. This is so we do not hardcode the value in flow. If we need to change this value in the future, we can update it in the Custom Metadata Type and not have to touch the flow.

• • Label: Get the Warning Threshold
  • Object: Generic Configurable Reference
  • Filter the Generic Configurable Reference Records by DeveloperName Equals AutoDeactivationWarningThreshold
  • How Many Records to Store: Only the first record
  • How to Store the Data: Automatically store all fields

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

Your completed Get Records flow element looks like this.

View image full screen

E. Drag another Get Records flow element to the canvas so that we can lookup the Generic Configurable Reference Custom Metadata Type to get the deactivation threshold.

• • Label: Get the Deactivation Threshold
  • Object: Generic Configurable Reference
  • Filter the Generic Configurable Reference Records by DeveloperName Equals AutoDeactivationThreshold
  • How Many Records to Store: Only the first record
  • How to Store the Data: Automatically store all fields

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

Your completed Get Records flow element looks like this.

View image full screen

F. We need a Decision flow element to determine if the user has exceeded the warning threshold for the days since the user’s login or if the user has never logged in, the days since the user record creation.

Label: Threshold Exceeded?

For the “Exceeded” outcome, we need to check that the Days Since Login is equal or greater than the warning threshold or Days since the Creation Date is equal or greater than the warning threshold and there is no last login information.

Default Outcome: Not Exceeded

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

Your completed Decision flow element looks like this.

View image full screen

G. Next, drag another Get Records flow element to the canvas so we can retrieve the manager’s email address so we can copy the manager in the email sent to the user.

• • Label: Get Manager’s Email
  • Object: User
  • Filter the User Records that meet these conditions: Id Equals {!$Record.ManagerId}
  • How Many Records to Store: Only the first record
  • How to Store the Data: Automatically store all fields

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

Your completed Get Records flow element looks like this.

View image full screen

H. We need another Decision flow element to determine if the user is already assigned to the permission set group and the action (add or remove the permission set group) that needs to happen.

Label: Warning or Deactivation?

For the “Exceeded” outcome, we need to check that the Days Since Login is less than the warning threshold or Days since the Creation Date is less than the warning threshold.

Default Outcome: Deactivation

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

Your completed Decision flow element looks like this.

View image full screen

I. Next, we will drag in an Action flow element. We will search on Send and select the Send HTML Email action.

Note: There are many options in this action. Please refer to the documentation on UnofficialSF for more information.

• • Label: Send Warning Email
  • HTMLbody: Include, {!WarningEmailTextTemplate} [See below on how to configure]
  • SendCCthisOneEmailAddress: {!Get_Manager_s_Email.Email}
  • SendTOthisOneEmailAddress: {!$Record.Email}
  • Subject: Warning: Your Salesforce Account May Be Deactivated Soon

Your completed Send HTML Action looks like this.

Create a text template called “WarningEmailTextTemplate.” This is our HTML email body for the warning deactivation email that will be sent to the user and their manager a week before the deactivation threshold to inform the user that they may be deactivated if they do not log into Salesforce.

• • Resource Type: Text Template
  • API: WarningEmailTextTemplate (I like ending my text templates with “XXXXTextTemplate”)
  • Body: (Note: {!Record.FirstName} represents the user’s first name. !Record is the global variable for the user record. {!Get_the_Deactivation_Threshold.Numeric_Data__C} indicates the deactivation threshold.

{!$Record.FirstName},

We’ve noticed that you have not logged in for a while. We have a policy that we will auto-deactivate any users who have not logged into Salesforce in over {!Get_the_Deactivation_Threshold.Numeric_Data__c} days. If you do not want your account to be deactivated, login now.

Thank you.

Your completed text template should look like this.

J. Next, drag an Update Records flow element to the canvas so we can deactivate the user.

• • Label: Deactivate the User
  • How to Find Records to Update and Set Their Values: Specify conditions to identify records, and set fields individually
  • Object: User
  • Filter the User Records that meet these conditions: Id Equals {!$Record.Id}

  • Set Field Values for the User Records: IsActive: {!$GlobalConstant.False}

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

Your completed Update Records flow element looks like this.

K. Now, drag in an Action flow element. We will search on Send and select the Send HTML Email action.

• • Label: Send Deactivation Email
  • HTMLbody: Include, {!DeactivationEmailTextTemplate} [See below on how to configure]
  • SendCCthisOneEmailAddress: {!Get_Manager_s_Email.Email}
  • SendTOthisOneEmailAddress: {!$Record.Email}
  • Subject: Your Salesforce Account Was Deactivated

Your completed Send HTML Action looks like this.

Create a text template called “DeactivationEmailTextTemplate.” This is our HTML email body for the deactivation email that will be sent to the user and their manager after the user is deactivated.

• • Resource Type: Text Template
  • API: DeactivationEmailTextTemplate (I like ending my text templates with “XXXXTextTemplate”)
  • Body: (Note: {!Record.FirstName} represents the user’s first name. !Record is the global variable for the user record. {!Get_the_Deactivation_Threshold.Numeric_Data__C} indicates the deactivation threshold

{!$Record.FirstName},

You have not logged into Salesforce in over {!Get_the_Deactivation_Threshold.Numeric_Data__c} days. Per our policy, we have deactivated your account. If you believe this was done in error, please contact your System Administrator, Addison Dogster.

Thank you.

Your completed variable should look like this.

L. 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.

M. Connect the flow elements, fault connectors and outcome connectors to match the below…

N. Save/Save As and provide the following properties.

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

[Summer ’20 Release or after] O. Before you activate your flow, test this by using the Debug button. The most recently updated record to be picked up in the scheduled flow will be the one used in the debugger. Check the Enable rollback mode checkbox so you don’t inadvertently update records while debugging.

P. Click the “Activate” button.

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

Deployment Notes/Tips:

• Flows, processes, custom metadata types and fields can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
• You will find the flows and/or a process in a change set under the Flow Definition component type.
• Custom metadata type records are also deployable under the Custom Metadata Type component type.
• The custom metadata type objects can be found in a change set under the name of the custom metadata type object.
• Activate the flow and process post deployment as flows deploy inactive in Production, unless you have opted in on the Process Automation Settings screen, to “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must cover at least 75% of the total number of active processes and active autolaunched flows in your org.