function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
jpollackjpollack 

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?

pbattissonpbattisson

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

jpollackjpollack

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?

pbattissonpbattisson

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 

jpollackjpollack

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.

dkadordkador

Keep that REST API code around.  My guess is we'll fix this soon.

dkadordkador

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.

jpollackjpollack

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.

jpollackjpollack

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?

dkadordkador

I spoke too soon.  This is a bug.  I'll try to get this fixed ASAP.

SuperfellSuperfell

Yes, the one marked active is the default.

jpollackjpollack

Thanks!  Please keep us posted.

KjWhalKjWhal

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)

jwolfjwolf

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.

dkadordkador

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?

jwolfjwolf

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.

dkadordkador

Glad to hear it's working for you now.  Don't hesitate to post if you find it's not working in the future.

uebayasiuebayasi

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

ddennddenn

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.

crispycrispy
Using REST API can we create a lead and skip the lead assignment rules? When we pass ownerid as one of the parameter, lead gets created and then the lead assignment rules are getting executing and changing the owner.
SFDCMattSFDCMatt
Seems like the Assignment Rules now have the option to fire or not using REST API, but there is no option to fire the assignment rule email notifications. Is this really true? Does anyone know how to get the Lead ARs to fire via a REST API submission AND get the notification email to go out?
Ron VictorinoRon Victorino
I am also having the same issue as SFDCMatt. Is there an additional option I can send in my call to SalesForce to trigger the email notifications?

The assignment rules are successfully triggered, but I need those e-mails to fire to notify our users when new leads come in.
Daniel MasonDaniel Mason
HI All,
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);
    }
}
Valts ZutisValts Zutis
Aim: Create a Lead round robin with email notification sent to newly assigned owner.

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

Process Builder - Lead Round Robin + Email Notification 
Adrian MonzonAdrian Monzon
Was the bug for REST API confirmed to be fixed? Still encountering the same issue where the Lead Assignment rules are bypassed.