You need to sign in to do that
Don't have an account?

REST API bypasses Lead assignment rules. Help!
I have an old application that uses Web-To-Lead. I'm updating it to use the REST API. We have a bunch of assignment rules set up for Leads. When we create a lead through Web-To-Lead, the Lead is assigned according to our assignment rules. However, when we create a Lead through the REST API, the assignment rules are completely ignored, and the Lead is assigned to the account whose credentials we used to authenticate through OAuth. This has slowed our sales team to a crawl, because now they have to assign leads by hand.
Any ideas how to fix this?
Hey jpollcak
I think I just answered your identical post on stack overflow. If not then visit the post anyway to see the answer.
Paul
Thanks for the help! However, the documentation that you linked to is for the SOAP API. How do I set the assingment rule header for the REST API?
It doesn't seem that you can which is a pain. You could try creating a new web service using the Apex REST services stuff (new in Summer '11) which then takles in your Lead data as you have created and runs it using the code at this link.
That should allow you to have the assignment rules run on the inserted Lead and still use a RESTful API. Your own implementation on Salesforce in fact. You could try that code in a trigger on Lead which should get run by the native API as well.
Hope that helps. Apologies for not paying attention on the SOAP REST thing first time round.
Paul
Thanks for the help! Yeah, I thought about using APEX for this, but the VP of sales at my company kinda nixed that.
I think this is a major oversight on the part of SFDC. I mean, how could they expect us to ditch our assignment rules just because we want to use the REST API? The SOAP API supports it just fine.
Anyway, we wound up falling back to WebToLead for lead creation. At some point we may give this another look and use the SOAP API, but for now I've got to move onto another project.
Sucks. I put a lot of work into the REST code. I'm disappointed in SFDC.
Keep that REST API code around. My guess is we'll fix this soon.
Actually, my tests indicate the default lead assignment rule /is/ applied. If you're sure your default assignment rule criteria are being met, can you post your organization ID here so I can take a peek at your setup? I'd like to make sure there are no other corner case bugs we're missing.
Here's our OrgID : 00D80000000aDQG
Our active assignment rule is called : Qualification Queue Lead Assignment
That rule specifies 7 different Rule Entries : 6 of them have criteria, the last one is the default. When we create leads through WebToLead, it goes through the Rule Entries one-by-one, in order, unitl it finds a match. If it doesn't find a match, it follows the default Rule Entry, which specifies that the lead should be assigned to a user named : Lead Qualification Queue - New
When we create leads through the REST API, it completely skips all of the Rule Entries and assigns the lead to the user we authenticated with through OAuth, which winds up being :
name : srypp
login : salesforce@rypple.com
According to the people I spoke with in customer support, there's no way to make the REST API respect our assingment rules when creating leads. They suggested an APEX trigger. This seems like a serious oversight.
Also, when you talk about the "Default Assignment Rule" what exactly are you referring to? When I see our list of Assignment Rules, I notice that one of them is marked "Active". Is this our "Default Assignment Rule?" If not, where can I find out what our Default Assignment Rule is? Where can I change it?
I spoke too soon. This is a bug. I'll try to get this fixed ASAP.
Yes, the one marked active is the default.
Thanks! Please keep us posted.
Has there been a resolution for this issue yet? I'm also curious whether or not it affects cases as well?
Is the default rule applied, or is it ignored (the post stating it was had something of a retraction afterwards)
So, to be clear you are saying that when creating sobjects through the REST api the default assignment rules are supposed to fire? I'm creating cases through the api and this does not appear to be the case. It seems silly to have to use the SOAP api if we want to have assignment rules be fired.
They are supposed to fire, yes. I believe I fixed this bug already. Do you have a repro case that shows it's not working for you?
Thank you for the response. This wasn't working for me yesterday, but it appears to be working now. Maybe we can chalk this one up to user error on my part.
Glad to hear it's working for you now. Don't hesitate to post if you find it's not working in the future.
I have the very opposite situation - I want to bypass the AssignmentRule via REST API. It seems that "Case" creation via REST is always applied & owner is re-assigned, which I don't intend.
I know there's a knob to controll that in the SOAP API..., but how to do that in the REST API?
TIA,
Masao
I too am having this problem... in fact I am inserting a child record that is related to case and even that is triggering the case assignment rule :( I need a way to insert the child record without triggering the assignment rule.
The assignment rules are successfully triggered, but I need those e-mails to fire to notify our users when new leads come in.
I recently encountered this problem whilst trying to integrate exact target. Exact target use something called “Ampscript”. I found out that Ampscript does not support the native Salesforce Lead Assignment. This requires you to set the AssignmentRuleHeader and add it to the header of web service call to the Salesforce API which is not exposed on the AMPScript calls. As it is not exposed, it is not possible for this to be applied.
however I got around it this way
*******************
* AssignleadsToQueue
* Trigger to fire assignment rule for ET Web leads
* Author: Daniel Mason
* Created: 12-05-2015
* Changes:
* LG CN21613 - 14-05-2015: Added check for User Id and call to LeadUtils class for processing
*******************/
trigger AssignLeadsToQueue on Lead (after insert)
{
Set<Id> leadsToUpdate = new Set<Id>();
Id APIUser = (Id)Label.ET_Web_User_Id;
for(Lead l : Trigger.new)
{
if(l.Ownerid == APIUser)
{
leadsToUpdate.add(l.Id);
}
}
if(leadsToUpdate.size() > 0)
{
bg_LeadUtils.InvokeLeadAssignmentrule(leadsToUpdate);
}
}
/*******************
* bg_LeadUtils.cls
* Utility class for Lead sObject
* Author: Daniel Mason
* Created: 12-05-2015
* Changes:
*******************/
public class bg_LeadUtils
{
@future
public static void InvokeLeadAssignmentrule(Set<Id> leads)
{
/*
Method to trigger Assignment Rule for new API Leads from ET
*/
List<Lead> updateList = new List<Lead>();
Database.DMLOptions dmo = new Database.DMLOptions();
dmo.assignmentRuleHeader.useDefaultRule = true;
for (Id l : leads)
{
updateList.add(new Lead(Id = l));
}
try
{
Database.update(updateList, dmo);
}
catch (DmlException e)
{
system.debug('LG*** error: '+e);
}
}
}
/****************
* bg_LeadUtils_Test
*
* Author: Daniel Mason
* Created: 14-05-2015
* Changes:
*
****************/
@isTest
public class bg_LeadUtils_Test
{
private static testMethod void TestInvokeLeadAssignmentrule()
{
/*
test method for InvokeLeadAssignmnetRule
*/
// create a ET Web User
User testWebUser = [SELECT Id FROM User WHERE Id = :Label.ET_Web_User_Id];
// retrieve appropriate Queue id
List<Group> LeadQueue = [SELECT ID FROM Group WHERE Name = 'Exact Target - TalkingPoint Global' AND Type = 'Queue'];
// create a Lead object to trigger Methods and Assignment Rule
Id LeadRecordType = bg_RecordTypeUtils.getRecordTypeIdByDevName('Exact_Target');
Lead testLead = new Lead();
testLead.Firstname = 'Test';
testLead.lastName = 'TestyBG';
testLead.Email = 'testyLead@Leadtester.com';
testLead.LeadSource = 'TalkingPoint Global';
testLead.Company = 'Brightgen';
testLead.RecordTypeId = LeadRecordType;
Test.startTest();
System.runAs(testWebUser)
{
insert testlead;
}
Test.stopTest();
// confirm Lead Owner is correct Queue
Lead confirmLead = [SELECT Id, OwnerId FROM Lead WHERE Id = :testLead.Id];
System.assertEquals(LeadQueue[0].Id, confirmLead.OwnerId);
}
}
I am using API connection (with Gravity forms) instead of Web-to-Lead and found myself in the exact same situation. As default Lead Assignment rules were overlooked by Salesforce instance, I found an alternative: Process Builder. I used this Salesforce knowledge article (https://help.salesforce.com/articleView?id=000004000&type=1) to create my Round Robin ID (Lead field) and then replicated "Lead Assignment Rule" structure with it. Works like a charm and has some extra flexibility.
Location: Create -> Workflow & Approval -> Process Builder