Skip to main content

Lead-to-Account (L2A) Matching in Demand Conversion Platform's Workspaces

Henrique Tein
  • Updated

Who can use this feature?

Available on All Products
Available to Admins Workspace Admins
Billing Center Get a Demo

When the triggered record is a Lead in Salesforce, but the evaluation of how to assign or make changes to this record is based on Account data, Chili Piper will need to use Lead-to-Account (L2A) matching logic to decide which Account to match to.

The Matching settings will be relevant to Distro, Concierge, Handoff, Chat, and ChiliCal Scheduling Links and their respective User Controls and CRM Actions.

This process involves initially following our default matching algorithm and subsequently configuring the settings that can be configured through the Matching settings page, which will be explained next.

Table of Contents:

How do I Access the Lead-to-Account (L2A) matching in a Workspace

It's important to mention that this setting is global, so it will be applied to all your Distro CRM Flow Builders, Concierge Routers, Handoff Router,  and/or Chat Journeys.

  1. In your workspace left-side menu, under Settings, click on the "Matching" option:


  2. There, you will initially see the "CRM Lead/Person to Account" tab, where you will notice the Default Chili Piper, Salesforce, Filtering, and Tiebreaker sections that will help you configure your Lead-to-Account (L2A) logic for the workspace.

    Each one of these sections will be covered in more detail below. 

    Before proceeding, notice the updates in this section are auto-saved, so there is no need to publish changes or confirm anywhere else.

Default Chili Piper and Salesforce

You can combine Chili Piper's matching algorithm with Salesforce deduplication rules to build your Lead-to-Account (L2A) matching logic, use just one of them, or disable both if it makes more sense to your use case. In this section, we will explain how the Default Chili Piper algorithm and the Salesforce one work.

By default, the Lead-to-Account is enabled, but you can fully disable it (or enable it back) by toggling the following button on/off:

Also, note that any updates done on this page are auto-saved.

 

Default Chili Piper

You will notice two different logics within the Default Chili Piper Algorithm: Contacts and Accounts. Let's cover them separately below:

Contacts

The algorithm will extract the record's (Lead) domain (acme) and extension (.com) to find Accounts that have Contacts with the same domain and extension in your CRM. If there's a match, then the related Account(s) will become a potential match:

 

Accounts

In addition, you can cast a wider net of possible Account matches. This setting will allow you to decide if the record should be included as a potential match if the Lead's email domain matches the Account's website domain field in your CRM, even if there are no matching Contacts.

If enabled, for this example, we would follow this logic:


You can enable or disable each of the algorithms explained above separately by toggling the On/Off button next to it. If you disable both, Chili Piper's algorithm will be consequently off.


Salesforce

In addition to the default Chili Piper algorithm, Chili Piper can leverage Salesforce Duplicate Rules to find more potential candidates for Lead-to-Account Matching.

You can enable or disable it using the button on the right:

If enabled, clicking the "Add Salesforce Duplicate Rule" will display the active Deduplication Rules you have in Salesforce. Click the checkbox next to the ones you want to add for evaluation to add them. 

You can also re-order the priority which these rules will be checked by dragging them:

If you notice some rules are grayed out, like the ones below, they are inactive in Salesforce. If you plan to use them in Chili Piper, activate them in Salesforce first.


What If We Have Multiple Matches?

If a prospect matches with multiple Accounts after checking your enabled algorithms, we will use Filtering and Tiebreakers to get the best result. 

Filtering

warning-icon.png Data Field Mapping

Filters rely on CRM fields. Ensure your Data Field mapping is set up correctly to avoid record leaks.
Check this article for more details on how to set up Data Fields for your team.

A filter can be used to tell Distro, Handoff, Concierge, and/or Chat which Account should be considered only if there is more than one possible Account matching after checking the default matching algorithm.

Two types of Filters can be created:

  • Account filters that include/exclude potential matches based on Account field values (Value).
  • Account/Lead comparison filters that allow you to include/exclude potential matches based on how field values compare to the Lead and potential Account matches (Lead/Person).

For example, suppose that johndoe@acme.com matches multiple "ACME" accounts in your Salesforce instance.

In this case, we can use Filters to narrow possible matches by setting. Let's see one example where we set two filters:

  • Account's Customer field should be the True AND
  • The Account Name does not contain the word "Test": 

Still using the same example, let's set one more Filter to check if the Account's Phone field is equal to the one as the Lead/Person's Phone field:

Always double-check if you are using the right operator (AND/OR). You can switch it by clicking on it:

Note: The fields used above are examples. In your workspace, you will see a complete list of standard and custom fields based on the configuration of your Salesforce instance.

Tiebreakers

warning-icon.png Data Field Mapping

Tiebreakers rely on CRM fields. Ensure your Data Field mapping is set up correctly to avoid record leaks.
Check this article for more details on how to set up Data Fields for your team.

If, after checking Filters, there is still more than one possible Account match, Tiebreakers can be used to prioritize further which Accounts should be selected.

Tiebreakers include standard and Smart field options to help you prioritize the right Account. There is no limit as to how many tiebreakers you can have. Additionally, you can create a list of Tiebreakers that can be ordered based on priority and help to match with the expected Account. 

Tiebreakers use the following operators:

  • is maximum - is the greatest of something; in the case of dates, this would be the most recent
  • is minimum - is the smallest of something; in the case of dates, this would be the least recent

In the example below, we created a list of Tiebreakers that will be checked from 1 to 3 until we have a match:

Note that the special Tiebreaker fields below are not standard fields in your Salesforce instance but rather special fields created by Chili Piper that are available for the Account object:

  • Number of matched Contacts
  • Number of Contacts
  • Number of Opportunities

You can re-order the priority of conditions by dragging the Tiebreakers up and down the list:

Also, it's important to note that the default Tiebreaker can't be deleted. It ensures that you have at least one unique match for evaluation. For example, you can re-order to be the last evaluated in the list, like in the above gif, where the Account Created is maximum Tiebreaker was moved from #1 to #3, but not removed from the list.

Lead-to-Account (L2A) Rules

Let's see how we can apply the L2A Matching to a real use-case example: 

These rules evaluate if the existing Lead matched Account (#1) OR if the net-new record's Account (#2) company size is 501-1000.

L2A rules also have two operators: null / is not null, allowing you to match and Enable the Lead to Account, making it easier to exclude Account-related rules when combining them with other objects.

null -> Maps to an empty field or a record that does not exist.

is not null -> Maps to a non-empty field or existing record.

These operators can be used to evaluate Account data if necessary. We can force object checks using this type of Rule (it works for any type of object).


Route to Any Salesforce Object

By working further within our integration with Salesforce to support ANY Salesforce Object (Standard or Custom), our Rule Builder supports more use cases.

Let's cover these settings below:

 

Lookup Fields or Other Fields

When you create a Rule, you can refer to a field on the object itself (first degree), but you can also refer to a related object field through a Lookup (second or more degree). Let’s say we want to search for the field Account on the Opportunity Object:

  • Lookup Fields (Relationship to another Object)
  • Other Fields (Opportunity Fields here)

In this example, we want to route any new Opportunity to the Account Owner. To achieve this, we will select the “Account” lookup field and then select the Owner ID of the Account:


Here is what the rule looks like:


We can also add one layer of complexity by ONLY routing these Opportunities WHEN the Account Owner is Active with these additional criteria:

From the Opportunity Object, we will select the Account Lookup, then the Owner Lookup of this Account (User Object), and retrieve the field: “Active”.

Here is the final result:

Exploring an additional use case, let’s say we want to route any new Contacts to the Parent Account. First, we will select the Contact Object, then the Account Lookup, then the Parent Lookup

It will look like this:

To achieve a Lead to Account Matching, for example, this relationship does not exist as these two objects are not connected in Salesforce's architecture:


The Rule will be configured this way:


The lookup: "Matched Account" is a smart field as it’s an inexistent relationship in Salesforce. Chili Piper plays its magic to create this connection between these two objects.

Click here if you'd like to learn more about how to build Rules for your Chili Piper products.

 

Related articles