Routing Rules for Concierge

In this article we will cover of the most common scenarios of routing rules you will need for your Router.

Think of Queue rules as "buckets" that will catch your inbound leads. You will likely need to create various types of Queues so that you 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 Router. Once you have all your Queues created, you can choose the ones you would like to enable on your Router and arrange the order that 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 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 Salesforce 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 have chose Algorithm type: Prioritize Routing Based on Ownership in your Queue settings. 

Object: Choose any for [Object] Owner 

Field(s): Email or UserId

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 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.

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 the Account is owned by liz@chilipiper.com. Both of these things must be true to match to 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, so we will 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 we will choose this Field here as well:

We used Related Lead for the object because this is what Chili Piper defaults to for routing net new Leads. We will automatically check for an existing record in Salesforce prior to 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 use the Lead rules as well.

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 Queue's 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 3-4.

Catch All Queue

A Catch All Queue, alternatively known as a No Criteria queue, does not have any rules. Creating a Catch All is best practice for your initial Router configuration to rule out any routing errors when testing the integration.