Salesforce Lead assignment rules ensure Leads are assigned to the appropriate user or queue for follow up. They also liberate marketers from trying to maintain sales territory logic within their Marketing Automation Platform (MAP).
>> Related: How to Build a SLA Alert in Salesforce <<
When a new Lead is created, Salesforce will use logic you’ve configured to assign the record to the appropriate user or queue. But what if you need to re-run that logic on existing records?
In this post:
Re-running Lead Assignments for just a few Leads
If you only need to do this for a single Lead record, the solution is simple. Edit the record and select the optional “Assign using active assignment rule“ checkbox.
If you need to do a one-time batch reassignment of a number of records, export the relevant Lead Ids. Then use the Apex Data Loader to trigger assignment rules to fire. You can grab the ID of the appropriate Lead Assignment Rule from the URL bar when viewing the rule in Setup. It will always start with the prefix “01Q”.
But you may want to automatically re-run Salesforce Lead Assignments
But you may want to re-run assignment rules automatically under certain conditions. For example: you may assign Leads under a certain Lead Score to a Queue. When the Lead Score increases over the threshold, you then want to re-run assignment rules to assign to an inside sales rep for follow up.
To do this, we combine Flow and an Apex Invocable method. We take advantage of the power of Apex with the flexibility to declaratively (clicks, not code!) control the logic of when to re-run the assignment rules, without having to edit any code.
Using Apex for Salesforce Lead Assignment Rules
Let’s start with the code.
Since we’re writing code here, we’ll need to start in a sandbox org first before deploying to production. You’re smart and already knew that you’d NEVER make changes in production without first testing in a sandbox (right?!), but in this case, Salesforce doesn’t trust you either way and forces you to write your code in a sandbox org before moving to production.
We’ll be creating an Apex class with a single method with the @InvocableMethod annotation, which allows us to call our Apex from within a Flow. The method accepts a single parameter (a list of the Lead Ids to be assigned) that you’ll pass into the method from your Flow.
public class RunAssignmentRules {
@InvocableMethod
public static void assignLeads(List<Id> leadIds){
Database.DMLOptions dmo = new Database.DMLOptions();
dmo.AssignmentRuleHeader.useDefaultRule = TRUE;
List<Lead> toAssign = [SELECT Id FROM Lead WHERE Id = :leadIds];
Database.update(toAssign,dmo);
}
}That’s it. Just those four lines are all you need in your code. The logic for firing the assignment rules will be configured in one or more Flows.
Now, in order to actually deploy this to your production org, you’ll also need to create a test class to cover your code and ensure that it functions as expected in your environment. A sample test class might look like this (but this is extremely basic):
@isTest
public class RunAssignmentRules_Test {
@testSetup
static void loadData(){
Lead l = new Lead(
LastName='Test',
Company='Test'
);
insert l;
}
@isTest
static void testLead(){
//instantiate List to pass to @InvocableMethod
List<Id> ids = new List<Id>();
//query for test data and add to List
Lead l = [SELECT Id, OwnerId FROM Lead];
ids.add(l.Id);
//call @InvocableMethod
test.startTest();
RunAssignmentRules.assignLeads(ids);
test.stopTest();
//verify that Lead was re-assigned
Lead res = [SELECT Id, OwnerId FROM Lead];
System.assert(l.OwnerId != res.OwnerId, res);
}
}Work with a developer to ensure you’re accounting for any requirements specific to your Salesforce instance.
Using Salesforce Flows for Lead Assignment Rules
Now we’ll create our declarative logic of when to fire the code, using a Flow.
1) Create a new Flow by searching for Flows under Setup and clicking the New Flow button in the top right. This example is for a Record-Triggered Flow, but you can design it a number of ways.
2) Select the Lead object for your Flow and configure the trigger for when a record is created or edited.
3) Then set the Entry Conditions. In this use case, we want to re-assign Leads after they meet a certain Lead Score. Select “custom condition logic is met.” Set the condition that the Lead Score is greater than or equal to 100.
Under the “When to Run the Flow for Updated Records” section, select the option to only execute when a record is updated to meet the condition requirements. This means we’ll only execute the actions if the record previously did not meet the criteria, but now does after being updated.
4) Without getting into too much detail, because of Triggers and Order of Execution, we can’t call our code in an immediate action. Instead, we’ll create a scheduled path to call our Apex method.
In this case, we want the logic to execute ASAP, so we’ll set the schedule for 0 minutes from now.
5) Once saved, we can create a new action. Click to Add a New Element, and select an Action type. Give your action a name, and select the Apex class you created earlier. Set the Apex Variables leadIds using the Field Reference of the Lead Id that started the process.
6) After saving, your Flow looks like this:
Activate your flow, test in your sandbox, and deploy to your production org. Since the code is fired under a scheduled action, there is a slight delay before the reassignment happens. In my experience, it’s usually <2 minutes, but you can monitor this under Setup > Flows and viewing the Paused and Waiting Interviews section.
The nice part about this approach is that if your requirements change – for example if your Lead Score threshold changes to 150 instead of 100 – you can change the logic in your Flow (Step 3) without having to touch any code.
