Submitting a Lead through the Composite endpoint of the REST API is not triggering the correct Lead assignment rule

Question

Update: The original question was missing some crucial details which were responsible for the issue, so they have been added in and are marked as part of the update.

---

Original Question

I'm working on an API that submits leads and associated objects to Salesforce via the Salesforce REST API using the composite request endpoint.

Issue

When inserting a lead as part of a composite subrequest the assignment rules are running but owner is not correctly assigned.

Example

In early subrequests we're making GET requests to retrieve objects and then using their values in later object creation.

Here's a rough example of how the composite request body:

{
  "allOrNone": false,
  "compositeRequest": [
    {
      "referenceId": "refAccount",
      "method": "GET",
      "url": "/services/data/v48.0/sobjects/Account/[account-id]?fields=Country__c,Lead_Record_Type_Id__c",
      "body": null
    },
    {
      "referenceId": "refLead",
      "method": "POST",
      "url": "/services/data/v48.0/sobjects/Lead",
      "body": {
        "FirstName": "TestLead",
        "LastName": "QueueTest",
        "Country__c": "@{refAccount.Country__c}",
        "RecordTypeId": "@{refAccount.Lead_Record_Type_Id__c}",
      },
      "httpHeaders": {
        "Sforce-Auto-Assign": "TRUE"
      }
    }
  ]
}

The value of refLead.Country__c is being replaced by the value of refAccount.Country__c.

An example of a similar rule criteria to what we are using looks like:

ISPICKVAL( Country__c , "UK") && ISPICKVAL( Other_Lead_Field__c , "Other Value") 

Updated: An additional check for the value of Other_Lead_Field__c has been added to the rules example. This field is not included in the initial submission as its value is automatically set by workflow rules.

When we make a submission where the value of refAccount.Country__c is "UK" we are finding that this rule is not applied.

Is it possible that the rules are being applied before values are replaced in the composite request?

Answer 1

Cause

The issue was caused by the assignment rule depending on a value that was set later on by workflows.

I've updated the original question to include in the example rule a check for the value of Other_Lead_Field__c which is later assigned by workflow rules as this was missing from the original question.

The issue was elusive because the values for the Lead we used to compare against the rule were retrieved by querying the Lead's fields after it had been inserted and its associated Workflows had ran. Following @sfdcfox's recommendation we set up logging and were able to identify that one of the rules values was not yet set.

Here's an an example what a snippet from the log file would might look like for the example provided in the question:

11:35:23.123 (...)|CODE_UNIT_STARTED|[EXTERNAL]|Workflow:Lead
11:35:23.123 (...)|WF_RULE_EVAL_BEGIN|Assignment

11:35:23.123 (...)|WF_CRITERIA_BEGIN|[Lead: TestLead QueueTest lead-id]|Default Lead Assignment Rules Name|rules-id
11:35:23.123 (...)|WF_RULE_ENTRY_ORDER|1
11:35:23.123 (...)|WF_FORMULA|Formula:ENCODED:[treatNullAsNull]ISPICKVAL({!ID:country-field-id}, "UK")  && ISPICKVAL( {!ID:other-field-id} ,"Other Value")|Values:Country__c =UK, Other_Lead_Field__c=null
11:35:23.123 (...)|WF_CRITERIA_END|false

As you can see it looks like Salesforce's implementation of Lead Assignment Rules use the same process as Workflow Rules. However, Lead Assignment Rules were running the workflow that assigned the value for Other_Lead_Field__c so it was still null.

For guidance of how to set up debug logs see the Salesforce documentation here.

Solution

We identified two ways to resolve this problem:

• Modify the Workflow that sets the value of Other_Lead_Field__c to "Other Value" to be triggered earlier. From the order of Workflow events I could see in the logs, this would need to be a trigger on the Lead object for either the after insert or before insert events. I guess that this is most likely the "best practice" solution. This documentation page may be helpful.
• A simple alternative is to send the correct value for Other_Lead_Field__c in the initial submission.

We decided to go with the latter. For example the new composite request looks like:

{
  "allOrNone": false,
  "compositeRequest": [
    {
      "referenceId": "refAccount",
      "method": "GET",
      "url": "/services/data/v48.0/sobjects/Account/[account-id]?fields=Country__c,Lead_Record_Type_Id__c",
      "body": null
    },
    {
      "referenceId": "refLead",
      "method": "POST",
      "url": "/services/data/v48.0/sobjects/Lead",
      "body": {

        "Other_Lead_Field__c": "Other Value",

        "FirstName": "TestLead",
        "LastName": "QueueTest",
        "Country__c": "@{refAccount.Country__c}",
        "RecordTypeId": "@{refAccount.Lead_Record_Type_Id__c}"
      },
      "httpHeaders": {
        "Sforce-Auto-Assign": "TRUE"
      }
    }
  ]
}