As leads come in, they are assigned to the lead queue and a Sales Rep picks up the lead to follow up/qualify. However, the Sales Rep may not get to the lead due to bandwidth issues, being out of the office, etc. You don’t want that lead sitting out there unattended. Rather, you’d want the system to automatically re-assign the lead back to the Lead Queue to be assigned to another Sales Rep.

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

• Familiar with custom settings? They are used to create custom sets of data, or to create and associate custom data for an org. If the data does not need to be associated to a profile or user, you will LOVE custom metadata types. The data records associated with a custom metadata type are deployable via a changeset and not wiped out with each sandbox refresh! You can locate the data records by looking for the custom metadata type’s name under the Component list when creating a changeset. For more information on custom metadata types, visit Salesforce Help & Training.
• Similar to a scheduled action in process builder, the wait visual flow element will wait for one or more defined events to occur, which allows you to automate processes that require a waiting period. For more information on the Wait Flow Element, visit Salesforce Help & Training.
• Avoid “hardcode” ID references in your process builder or visual workflow. Otherwise, you will have different versions of a process builder or flow in the different regions of your org. Instead, reference the ID in a custom metadata type/custom setting where you can modify the data there versus modifying the process builder or flow itself.
• 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 noting the data stored in a custom field, providing the purpose of a process builder, etc.
• For any data actions (fast and record lookup, create, update and delete actions) performed in visual workflow, best practice is to include a flow element to send an email to your Salesforce administrator about the fault.

Flow trick: To getting the Fault connector to appear, either draw the regular connector link to another flow element or connect it to a temporary flow element. Draw the fault connector to the Send Email element. Then, go back and delete the regular connector.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sammy Sunshine is the Sales Manager. Currently, Sales Reps go to the lead queue and assign lead records to themselves. However, due to a Sales Rep’s workload, s/he may not get to a lead in a certain number of days. The Sales Manager is running a Leads without Activities report and is finding leads that haven’t been contacted in 7 days. Sammy is manually reassigning the leads back to the lead queue. He would like Salesforce to re-assign the lead back to the queue after 7 days of inactivity from the lead assignment.

Solution: Addison is able to solve this declaratively by creating a custom lead field to store the date the lead is assigned to a user, custom metadata type to store the lead queue SFDC ID and the number of days of inactivity threshold, process builder and visual workflow to stamp or remove the date of user assignment or re-assignment of the lead to the lead queue after a certain number of days of inactivity.

Quick Steps:

This assumes that you have already created the lead queue in the Salesforce org.

1. Create a custom user field (Customize | Leads | Fields) called Date Lead Assigned to User. The FLS should be set to be visible and editable by the System Administrator and the Sales Rep. This field does not need to appear in the lead page layout. The field is meant to be a processing field and used behind the scenes.

Best practice tips:

• Don’t forget to provide a description so you and other/future admins know what this custom field is used for.
• Set the FLS (field level security) for each profile. Only make the field visible and editable for the profiles that need it. Do not just click the “Next” button when you are on the screen.

2. Create a custom metadata type (Develop | Custom Metadata Types). Click on the New button.

A. Provide the label name “Flow/Process Builder Reference” and label name in plural and save.

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.

B. Create a custom field with the name of the lead queue in your org. In this example, I’m calling this field “JenLeadQueue ID” per the screenshot below.

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.

C. Create a custom field called Lead Activity Threshold per the screenshot below. This will hold the # of days of inactivity before the lead is re-assigned back to the lead queue.

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.

This is the end result of Steps 2A-C.

D. Create the data record by clicking on the Manage Flow/Process Builder References button. Click on the New button.

Provide the Master Label “Reference”, Object Name (same as Master Label), the SFDC 18 character ID for the Lead Queue and the number of days for the lead activity threshold.

Note: You can locate the 15 character SFDC ID of the lead queue by navigating to the record and copying the ID from the URL. Then place it into a converter tool to convert the 15 character SFDC ID to the 18 character SFDC ID.

3. Create a visual workflow (Create | Workflows & Approvals | Flows). Click on the New button.  

This visual workflow will determine if a lead is assigned to a user and if so, it will stamp the date assigned field and after X number of days after the lead assignment, if there are no associated tasks or events for the lead, the lead will be re-assigned to the queue. If the lead is assigned to the queue, the system will remove the lead assignment date.  

A. Create the following 6 variables to match the screenshots below upfront. These will be used in the various flow elements.This can be done by going to the Resources Tab and creating a variable.

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 a Wait flow element. If the lead is assigned to a user, we will pause the flow starting with the date that the user is assigned to the lead until the number of days of inactivity has passed.

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

We will make this an absolute time alarm.

For the Base Time, we want to use the variable {!varLeadModifiedByDate} which tells this to start using the date that the user was assigned to the lead [Note: This variable will be passed to us in the process builder that will be created in Step 4.]

Add an Offset Unit. Here, we will specify “Days”

Add an Offset Number. We will create a new variable and call it “{!varNumberofDays}”

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

Click on the trash can for the record listed under the Variable Assignment section. If you do not delete this, you will not be able to save the Wait element.

Here is the end result of your Wait flow element.

C. Create a Record Lookup flow element. This will lookup the Task object and try and find a task record tied to the lead. We will use the criteria where the WhoId (this is the lead/contact associated to the task) matches the LeadID record (stored in the variable varLeadID). [Note: The LeadID will be passed to the visual workflow in the Process Builder that will be created in Step 4.]

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

If any task is found, it will assign the ID to the variable varTaskID.

Check the box “Assign null values to the variable(s) if no records are found”

D. Draw the connector “Wait time” from the Wait Flow Element to the Record Lookup Flow Element.

E. Create a Record Lookup flow element. This will do a lookup to the Custom Metadata Type “Flow_Process_Builder_Reference__mdt” created in Step 2 using the criteria where the MasterLabel equals Reference (this is the data record created in Step 2D. Once the system finds the record, it stores the the values in the two custom fields in the variables created in Step 3A.

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. Create a Decision Flow Element. This step will determine whether the owner of the lead is a user or the lead queue. Based on the decision, it will go down one of two paths.

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

For the Outcome LeadOwnerID is Not the Lead Queue, the condition is Lead Owner ID does not match the Lead Queue ID.

For the Outcome LeadOwnerID is Lead Queue, the condition is Lead Owner ID matches the Lead Queue ID.

G. Create a Record Update flow element. When the lead is assigned to the user, this will stamp the Date Lead Assigned to User field created in Step 1 with the Modified By Date.

It looks up the lead object where the ID matches the LeadID (varLeadID) and once found, it will update the custom field Date_Lead_Assigned_to_User__c with the date stored in the variable varLeadModifiedByDate.

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

H. Create a Record Update flow element. When the lead is re-assigned to the lead queue, this will update the date in the Date Lead Assigned to User field created in Step 1 with a blank date.

It looks up the lead object where the ID matches the LeadID (varLeadID) and once found, will update the custom field Date_Lead_Assigned_to_User__c with a blank value.

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

I. Draw the “LeadOwnerID is Not the Lead Queue” connector from the Decision Flow Element to  the Record Update Flow Element created in Step 3G. Next, draw the “LeadOwnerID is Lead Queue” connector from the Decision Flow Element to the Record Update Flow Element created in Step 3H.

The end result should match the illustration below.

J. Create a Record Lookup. This will lookup the Event object and try and find an event record tied to the lead. We will use the criteria where the WhoId (this is the lead/contact associated to the task) matches the LeadID record (stored in the variable varLeadID). [Note: The LeadID will be passed to the visual workflow in the Process Builder that will be created in Step 4.]

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

If any event is found, it will assign the ID to the variable varEventID.

Check the box “Assign null values to the variable(s) if no records are found”

K.Create a Decision Flow Element. This step will determine whether the lead has activity. Based on the decision, it will either end the flow or go down another path.

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

For the Outcome No Activity for the Lead, the condition is the lead does not have a task or an event (varTaskID and varEventID are null).

The default outcome is There is activity on the lead.

L.Create a Record Update Flow Element. This will update the lead and change the ownership from the user to the lead queue. It will lookup the lead object where the ID matches the variable varLeadID and update the OwnerID field with the variable varLeadQueueID.

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

M. Draw the Decision Connector “No Activity for the Lead” from the Decision Flow Element to the Record Update Flow Element.

N. Draw the other connectors between the flow elements.

[Note: The visual flow diagram includes the Record Lookup element: Using Custom Metadata Type in Visual Workflow Fault Email.

O. As a best practice, where there is a DML action (fast or record create, update, delete or lookup action) in a flow, you should also include notification of a flow fault.

Note: To avoid “hardcoding” email addresses in a fault email, refer to a post Using Custom Metadata Type in Visual Workflow Fault Emails.

Select the Send Email flow element that is listed under Static Actions, not under Quick Actions.

Best practice tip: Don’t forget to provide a description so you and other/future admins know what this send email element is supposed to do.

Configure the body to show the fault message, subject and email address(es).

Body: Fault Message: {!$Flow.FaultMessage}

Subject: Error: Re-Assign Lead Ownership to Lead Queue

Email Addresses (comma-separated): <email address>

You will need to draw a connector line between the Record Lookup, Record Update and Send Email elements.

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.

[Note: The visual flow diagram includes the Record Lookup element: Using Custom Metadata Type in Visual Workflow Fault Email. If you choose not to implement that, your starting element is the Record Lookup “Lookup data from the Custom Data Metadata Type Flow Reference”.]

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

Q. Click the “Close” button.

R. On the flows screen, activate the flow.

4. Create a process builder (Create | Workflows & Approvals | Process Builder). Click on the New button.

The process builder will invoke the visual workflow created in Step 2 for a new or existing lead where the OwnerID field is changed and the lead is not converted.

A. Create a new process. Give it a name, description and save.

B. Specify Lead as the object and save.

C. For the node criteria, provide a criteria name. specify as the criteria for executing actions as “Conditions are met”.

This will execute if the lead’s owner ID field is changed and the lead is not converted.

D. Add an immediate action, with the action type “Flows”. Name the immediate action, specify the visual flow created in Step 3. We will set two variables to pass to the flow and pass the lead’s record ID in the varLeadID variable and the lead’s last modified date in the varLeadModifiedByDate variable.

varLeadID reference [Lead].Id

varLeadModifiedByDate reference [Lead].LastModifiedDate

Click the Save button.

E. Click the Activate button in the upper right hand corner. Click the “Ok” button.

 

That’s it. Congrats, you’ve implemented the solution!

Now, before you deploy the changes to Production, you need to test your configuration changes. For testing purposes, assign the Days of Inactivity Threshold to 1 day.

1. Assign lead “A” to a sales rep.
2. Create a task for lead “A” as the sales rep.
3. Assign lead “B” to a sales rep.
4. Create an event for lead “B” as the sales rep.
5. Assign lead “C” to the sales rep
6. Create a task and event for lead “C” as a sales rep.
7. Assign lead “D” to the sales rep.
8. The next day, confirm that lead “D” is the only lead assigned back to the Lead Queue.

Deployment Notes/Tips:

• The custom lead field, custom metadata type and associated data record, process builder and visual workflow can be deployed to Production in a change set.
• The field level security for the custom lead field will need to be manually updated post deployment. I would caution against adding the related profiles in the changeset for deployment as the results of deploying a profile are not reliable. If you have a tool like Snapshot by Dreamfactory, you can use the tool to deploy field permissions.
• You will find the custom metadata type information under the Custom Metadata Type in the Component Type dropdown. However, locate the data record for the custom metadata types by looking for the custom metadata type name in the Component Types dropdown.
• You will find the process builder and visual workflow components in a change set under the Flow Definition component type.
• Activate the visual flow and process builder after they are deployed in Production as they are deployed as inactive.