Who can use this feature?
An Assignment Table holds your routing data – territories, segments, company sizes – next to the person or distribution each combination should go to. An Assignment Rule points at the table, so one path serves every row instead of one path per territory.
The table is a workspace asset in its own right. The same table can serve Distro, Concierge and Web Experiences, so a territory change lands everywhere at once.
Table of Contents
- How an Assignment Table works
- Before you start
- Attributes
- One column serving more than one object
- Assignments
- Row order and no-match behaviour
- Creating a table
- Building the Assignment Rule
- Editing a table with CSV
- Using a table in your flow
- Limitations
How an Assignment Table works
A table has two kinds of column, which the table editor groups under Attributes and Assignments:
- Attributes hold the values a rule matches on, such as country or company size;
- Assignments hold the result – the user or team the matched row routes to.
You build one Assignment Rule that points at the table. The rule's conditions compare your record or form data against the input columns. At routing time, Chili Piper reads the table from the top and takes the first row where the rule is true.
One rule against a 60-row table replaces 60 near-identical paths.
Before you start
- Every user or distribution a row assigns to has to exist before the row can reference it. Create your distributions first;
- Give your distributions distinct names. See the warning under Editing a table with CSV.
Attributes
Each attribute column is a variable your rule can compare against. Select Add Column, then Attribute, and give it a name and a type. The type decides what a cell can hold, and the column header carries its icon.
| Type | Icon | Holds |
|---|---|---|
| Single Text Value | = |
one value, such as a country |
| Number | # |
one number |
| True or False | checkbox | a yes or no |
| Multiple Text Values | [ ] |
several values in one cell |
Matching a picklist with Multiple Text Values
Your segments rarely line up one-to-one with a picklist. A company-size picklist might run 1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10001+, while your territories are simply enterprise, mid-market and SMB.
Give the column the Multiple Text Values type and list the picklist values that make up each segment in one cell, then use the is any of operator in the rule:
| Country | Company Size | Routes to |
|---|---|---|
| United States |
1001-5000, 5001-10000, 10001+
|
enterprise |
| United States |
201-500, 501-1000
|
mid-market |
| United States |
1-10, 11-50, 51-200
|
SMB |
One row per segment instead of one row per picklist value. Take the values from the picklist itself rather than typing them – a value that does not match the picklist exactly will never match a record.
The same table can carry columns for more than one object. A row can hold values for a person, a company and a CRM record together, and the rule combines them:
In the rule builder you do not type the column name. You select the object and field on the left, choose an operator, and then pick the table column from the list on the right.
The column type does not have to match across objects – a text column holding 1000+ and a number column holding 1000 can sit side by side. What does have to match is the values. A rule comparing United States against a column holding US will never match.
One column serving more than one object
A column is a value, not a field. Nothing ties it to the object it was named after, so two conditions on different objects can read the same column.
Where both objects hold the same kind of value, use one column for both. Person country and account country are both country names, so a single Country column serves the person condition on one side of the rule and the account condition on the other. A four-column table collapses to three:
| Column | Read by |
|---|---|
| Country | the Person data field condition and the Account condition |
| Company Size | the Company data field condition |
| Account Employees Over | the Account condition |
Split into two columns only where the values genuinely differ. A company-size picklist value of 1001-5000 cannot be compared with an employee count greater than 1000 – one is a label, the other a number – so those stay separate.
Fewer columns means a narrower table, fewer cells to fill on every row, and fewer places for a row to be skipped for a missing value.
Empty cells
By default, an empty input cell means "this field must be empty". It does not mean "any value". A row with an empty Postal Code cell matches only records that have no postal code at all, so the row is skipped for every real record.
This matters when some rows are deliberately less specific than others. A table might route three named postal codes to specialists and everything else in the country to a general team. The general row leaves Postal Code empty, and by default it never matches.
To change that, open the condition's ... menu and select Treat empty cells as a match.
The condition becomes a sub-group joined by OR: the original check, or the column being empty. Rows that fill the column and rows that leave it empty are then both evaluated.
The option appears on conditions that use an Assignment Table column, and it is off until you add it.
Add it to every column that is blank on some rows and filled on others. Leave it off for columns every row fills. In the example above, Country is on every row so it does not need the option, while Company Size and Account Employees Over are empty on the least specific row and do.
Note: Each group is evaluated on its own. A rule that checks person fields in one group and account fields in another needs the option on the optional columns of both, or the row matches on one route and not the other.
Ranges
There is no range column type. Express a range with a separate column for each end, and use the greater than or less than operator in the rule. A column named Account Employees Over holding 1000, compared with greater than, gives you "over 1,000 employees".
Note: When the record has no value at all for a number field, it is read as zero. A record with no employee count therefore satisfies "fewer than 1,000 employees". Add a condition that the field is not empty if this matters to your routing.
Assignments
Add Column offers three kinds of assignment column, each serving a different part of the platform:
| Column | Used by | How many |
|---|---|---|
| Meeting Assignment | Meeting assignment in Concierge and Web Experiences | Several |
| Record Assignment | Distro record assignment, and the Assign To node in Concierge and Web Experiences | One |
| Conversation Assignment | Reserved for Live Chat routing only (coming soon) | One |
A table can carry several Meeting Assignment columns. Once it has a Record Assignment column and a Conversation Assignment column, those two options are no longer offered.
Note: A Conversation Assignment column can be added today and will be supported by Live Chat imminently.
Each cell in an assignment column holds either a specific user or a distribution, chosen per row. One row can route to a named user and the next row to a distribution, which selects the user by round robin.
More than one meeting assignment
A table can hold several Meeting Assignment columns, and each assignee slot picks its own. This is how double round robin works: Assignee 1 comes from a Meeting Assignee column and Assignee 2 from a Solutions Engineer column.
A single path can also read columns of different kinds from the same row — a meeting assignee and a record owner, for example.
A row must fill every column its path reads
The columns a path asks for come from its nodes, not from the row. A Display Calendar with two assignees asks for both columns on every record it evaluates.
⚠️ Warning: A row that leaves one of those columns empty does not fail the rule. It is skipped, and the next row down assigns the record instead.
Worked example. A flow books a meeting with two assignees, so it reads Meeting Assignee and Solutions Engineer.
| Row | Company Size | Meeting Assignee | Solutions Engineer |
|---|---|---|---|
| 1 | enterprise | US Enterprise AE | US SE Pool |
| 2 | mid-market | US Mid-Market AE | US SE Pool |
| 3 | SMB | US SMB AE | (empty) |
| 4 | any | US General AE | US SE Pool |
An SMB record matches row 3 on its attributes. Row 3 has no Solutions Engineer, so it is skipped and row 4 assigns the record – a different AE from the one the table appears to promise.
Covering tiers that do not all need the same assignees
Leaving a cell empty is not how you say "SMB does not need a Solutions Engineer". Two ways to do that:
-
Two paths, one table. An enterprise and mid-market path whose Display Calendar has two assignees, and an SMB path with one. Each path asks only for the columns its own nodes bind, so the SMB path never asks for
Solutions Engineerand the empty cell is fine. Two paths instead of one, rather than one per territory; - Two tables. Worth it only when the groups differ on attributes as well as on assignees.
Row order and no-match behaviour
Rows are evaluated from the top, and the first matching row wins. Put your most specific rows first.
A practical order is most granular to least: rows matching on country, state and postal code above rows matching on country and state, above rows matching on country alone. The order of the conditions inside the rule makes no difference – only the order of the rows matters.
Several rules can share one table, each using a different subset of the columns. A rule that reads fewer columns matches more rows, so check the order from the point of view of every rule pointing at the table.
When no row matches, the Assignment Rule evaluates as false, exactly like any other rule that does not match. The path does not run, and routing continues to the next path and then to your catch-all.
Creating a table
Assignment Tables live alongside your rules. Open the Rules asset in your workspace and select the Assignment Tables tab.
- Select the Assignment Tables tab;
- Create a table and give it a name;
- Select Add Column, then Attribute, for each value you want to match on;
- Select Add Column, then the assignment kind you need, for each result the table should produce;
- Select Add row and fill the cells, or load them with CSV Options.
Building the Assignment Rule
An Assignment Rule is a rule like any other, with one difference: it points at a table, and its conditions compare incoming data against that table's attributes. The rule header shows Assignment as its type, and your rule list groups these rules together.
- Select Create Rule, then Assignment. The three rule types are CRM Ownership, Without Ownership and Assignment, and the type is chosen when the rule is created;
- At the top of the Configuration tab, select the Assignment Table the rule reads;
- Add your conditions. On the left, choose the object and field as you would in any rule – Person, Company, or a CRM object such as Lead, Contact or Account. On the right, choose the table attribute instead of typing a value;
- Group the conditions, and set each group to AND or OR to match how your attributes are laid out;
- Publish the rule.
You can change which table a rule points at. Chili Piper warns you first: changing the table clears every condition that references an attribute from the current table, so those conditions have to be rebuilt against the new table's attributes.
Editing a table with CSV
Open CSV Options above the table for Download CSV and Upload CSV. Download the table, edit it in a spreadsheet, and upload it back. Downloading a table with no rows gives you the header row on its own, which is the quickest way to get the correct format.
The header row is built as follows:
- one column per attribute, headed by the column name;
- two columns per assignment column, headed by the column key – first
<key>_type, then<key>.
Column keys are the column name in lowercase with spaces replaced by underscores, so an assignment column named Solutions Engineer has the key solutions_engineer.
| Cell | What to enter |
|---|---|
| Attribute | the value. A Multiple Text Values cell holds its values separated by commas, with the cell quoted |
<key>_type |
user or distribution
|
<key> |
the user's email address, or the distribution's name |
⚠️ Warning: Uploading a CSV replaces every row in the table. It does not merge with the rows already there. Download the current table first and edit that file, so nothing is lost.
⚠️ Warning: Distribution names are not unique within a workspace. If two distributions share a name, an upload referring to that name resolves to one of them without telling you which. Give your distributions distinct names, or enter the distribution's ID in the cell instead of its name.
Upload tells you exactly what failed: unrecognised column names, a header it cannot read, a row with the wrong number of cells, email addresses that match no user, distribution names that match no distribution, and values that do not fit the column's type.
Using a table in your flow
The table sits inside the rule, so there is no separate node to add. Point a Routing Rule node at your Assignment Rule, then tell the assignment node which column to read.
Rule and node pickers filter by rule type, so only Assignment Rules appear where one is required.
Distro
On the route, set the assignment to come from the Assignment Rule rather than a fixed distribution. The route then assigns from the Record Assignment column of whichever row matched, and your Update Ownership action writes that owner to the record.
One route replaces one route per territory. A table of sixty rows is still one route.
When you add the Assign & Update Ownership node to a route that already uses an Assignment Rule, the assignee locks to Assignee from Assignment Rule automatically – there is nothing to select.
Note: Fallbacks are not available on a route that uses an Assignment Rule.
Reading the logs
The log for a routed record shows the whole table with the matched row highlighted, and the assignee that row produced. You can see what the table did without opening the table.
Above it, the log states which objects reached the rule and shows every condition with the data it was evaluated against. A condition on an object that does not exist for that record evaluates as false rather than failing the rule, which is what lets one table serve more than one object.
Limitations
- There is no date attribute type. Columns hold a single text value, a number, a true or false, or multiple text values;
- There is no range type. Use a column for each end of the range and a greater than or less than operator;
- A table holds one Record Assignment column and one Conversation Assignment column. Meeting Assignment columns are not limited;
- Assignment columns set the assignment only. They cannot populate field updates or add a record to a campaign;
- Meeting types cannot be set per row;
- Ownership cannot be used as an attribute column. An owner field can still be compared like any other field;
- Fallbacks are not available on a path that uses an Assignment Rule;
- Live chat routing cannot read a Conversation Assignment column yet;
- Assignment Tables are not available in Handoff.
Comments
0 comments
Please sign in to leave a comment.