In this article, we will cover the most common scenarios of routing rules you will need for your Inbound Router.
Think of Queue rules as "buckets" that will catch your inbound leads. You will likely need to create various types of Queues to have a bucket for every scenario you want to allow someone to schedule, such as East Territory US vs. West Territory US or Mid-Market vs. Enterprise.
Your Queues are not working for you until you enable them on your Inbound Router. Once you have all your Queues created, you can choose the ones you would like to enable on your Inbound Router and arrange the order we evaluate them in.
By default, we will always group and check Ownership Queues first, followed by Queues with rules, then Queues without rules.
We will create examples for the following:
- Route to an existing Owner
- Route to a named Account/Company Owner using a custom field
- Route using data from your form
- Exclude public domains
- Catch All Queue
Route to an existing Owner
Depending on your CRM's flow, you may or may not choose to route to the Owner of existing records.
To Route to an Existing Owner, you will first want to make sure you choose Algorithm type: Prioritize Routing Based on Ownership in your Queue settings.
Object: Choose any for [Object] Owner
Field(s): Email or UserId (Salesforce) / Id (HubSpot)
Value: Assignee Email Address or AssigneeId
Here we have rules for Lead, Contact, and Account Owner:
Notice how the logic was adjusted to reflect: 1 OR 2 OR 3. Another version of this logic based on common routing scenarios could state: 2 OR (1 AND 3)
Route to a named Account/Company Owner using a custom field
It's common to have a custom field in Salesforce for Named or Target accounts. In most cases, this is a checkbox field with a value of TRUE/FALSE or a Lookup field to the User populated with the Owner of the Account or Company.
Object: Account/Account Owner
Field(s): Custom field(s)
Value: Full Assignee Email Address or AssigneeId
Here is an example of Queue configured to route to Liz if the account is marked as a Target Account and liz@chilipiper.com owns the Account. Both things must be true to match this queue, or the Account SDR Owner must be a specific SDR - as denoted by their 18-digit Salesforce UserId.
Note: If you have the 15-digit UserId, this will need to be converted to their 18-digit UserId.
These queues reference specific assignee emails, so once you have a version created for one user, you will need to Duplicate this queue and create one per sales rep. Make sure to prioritize them first on the Router!
Route using data from your form
This step will require you to map your form to Chili Piper first. In this example, we have this form mapped, and we want to route based on Company Size:
Our routing plan will be as follows:
- 1-10: Disqualify
- 11-50: Disqualify
- 51-250: Route to Alex
- 251-1K: Route to Amanda
- 1K-5K: Route to Nate
Values 1-10 and 11-50 we want to disqualify to exclude them from our queue rules. Let's create Alex's Queue:
Object: Related Lead
Field(s): Custom field mapped to the Lead in your form mapping
Value: API name as shown in the form code
We are using Company_Size__c in the form mapping so that we will choose this Field here as well:
We used Related Lead for the object because Chili Piper defaults to routing net new Leads. We will automatically check for an existing record in Salesforce before routing it based on an email match - if none of your other queues match, we'll route it according to your Related Lead rules. If it's an existing Lead, we'll also use the Lead rules.
Be sure to copy the API names of the values from your form, specifically what appears after value= in the form code. In some cases, the value matches the label, but not always:
We can Duplicate Alex's Queue and change the Value to create Amanda's Queue:
And Nate's:
Since these queues do not have any overlapping criteria, the order on the Router will not matter.
Exclude public domains
Should you decide to filter out leads with a @gmail.com, @yahoo.com, @comcast.net, etc. domain from scheduling, add a rule per domain you would like to exclude in your queues using the not contains operator, like this:
Notice how the logic says: 1 AND 2 AND 3 AND 4, since a business email domain will not contain all of the public domains listed in Rules 2-4.
We have also simplified this process by adding the "ContainsNoneOf' operator. Now, you can create comma-separated lists of domains, e.g.:
Catch All Queue
A "Catch All Queue", alternatively known as a "No Criteria queue", does not have any rules. Creating a Catch All is the best practice for your initial Router configuration to rule out any routing errors when testing the integration.
For example, if you implement a queue without any rules and add it to your Inbound Router, you are sure to match to this queue at the very least. You can use this for testing that the inbound router is functioning correctly before implementing more advanced rulesets.