Router conditions
When a queue item is sent from your system to e-satisfaction through the events router, a router condition decides which pipeline it flows through — and therefore how the responder receives their survey invitation. Each router condition links one survey to one pipeline and says, with a set of rules, when queue items should be routed that way. They're the targeting layer in front of the dispatch queue.
Every router condition that matches creates its own queue item. So if two conditions match the same transaction — one pointing at an email pipeline and one at an SMS pipeline, say — the responder is sent both invitations.
Two ways to match
Every router condition matches in one of two styles, and you can switch between them at any time.
Channel match
The quick option. It matches against the responder's contact identifier with one of three shorthands:
- Any channel identifier — match whenever a contact identifier is present, whatever its format (email or phone).
- Email only — match only when the identifier is present and is a valid email address.
- Phone only — match only when the identifier is a phone number made up of exactly 10 digits, with no spaces, symbols or country prefix.
This is ideal for splitting an email pipeline from an SMS or Viber one without writing any logic.
Custom rules
The full builder. You combine rules with AND, OR and NOT over questionnaire metadata and responder metadata. Each rule names a field, picks an operator, and — for most operators — a value to match. You can nest groups inside groups, and negate any group with its NOT switch, to express conditions of any shape.
The operator set
Custom rules offer the full operator list:
- equal
- less, less or equal, greater, greater or equal
- begins with, contains, doesn't contain, ends with
- regular expression — match against a pattern
- is empty, is not empty — presence checks that take no value
- exists, not exists — presence checks that take no value
When an operator needs no value (the presence checks), the value box simply disappears.
Building a router condition
Open router conditions
Go to Survey Manager → Router Conditions to see your router conditions.
Add a router condition and name it
Choose Add condition and give it a clear name — something like Returns survey · email — so it's easy to find later.
Pick the destination
Select the workspace, then the survey, then the pipeline the matching queue items should flow into. The pipeline fixes the channel.
Define when it matches
Choose a quick channel match, or switch to custom rules and build your AND/OR/NOT logic against the queue item's metadata.
Save
Save the router condition. It applies to new queue items arriving through the events router straight away.
The survey and pipeline are fixed once created
When you edit an existing router condition, its workspace, survey and pipeline are locked — you can change the name and the matching logic, but not the destination. To route to a different pipeline, create a new router condition.
The router conditions table
All your router conditions sit in one searchable table showing each condition's name, its survey (and owning workspace), the pipeline and channel it routes to, and a summary of its rules. The search box filters by survey or pipeline. From any row you can Edit the router condition or delete it — deleting stops that routing immediately and can't be undone.
Importing router conditions in bulk
If you have a lot of router conditions to set up, import them in one pass from a CSV file or a Google Sheet through the mapping wizard.
Choose your source
Download the template if you're new to it, fill it in, then either upload it as CSV or paste a Google Sheet link. For a Google Sheet, share the file with the service account shown in the dialog (Viewer access is enough) before pasting the link.
Map your columns
The wizard guesses how your columns line up with the router condition fields — survey, pipeline, field, comparison criteria, plus optional value and name — and you confirm or correct each mapping. Survey, pipeline, field and criteria are required.
Preview before saving
Every router condition is previewed before anything is written. Each is flagged Create or Replace (one for the same survey and pipeline already exists), and you choose how its rules combine — AND or OR, optionally negated — per row or for all at once. Rows whose criteria text wasn't recognized are flagged and default to equal so you can review them.
Import
Confirm that you've checked everything, then run the import. Progress shows how many router conditions were created, updated or failed.
Update vs create on import
Import doesn't match rows on the router condition's name. It matches on the survey + pipeline pair — the same pairing that uniquely identifies a router condition (its survey and pipeline are fixed once the condition exists). That pair decides whether each group of rows updates an existing router condition or creates a new one:
- No router condition yet for that survey and pipeline → the group is flagged Create and a brand-new router condition is added.
- A router condition already exists for that survey and pipeline → the group is flagged Replace, and that router condition is updated in place: its name and its full set of rules are overwritten with what's in the file.
Because matching is on the survey + pipeline pair, every row in your file sharing the same survey and pipeline is merged into a single router condition — so list each rule on its own line, and they'll combine under the AND/OR/NOT logic you pick in the preview.
Replace overwrites — it doesn't merge rules
A Replace swaps in the imported rules wholesale; it does not add them to the router condition's current rules. If you want to keep a router condition's existing rules, include them in the file alongside the new ones. Every Replace is flagged in the preview before anything is written, so you can check first. (If more than one router condition somehow exists for the same survey and pipeline, the import updates the first one.)
Field names are used as-is
In an imported file, the field column is taken verbatim, so enter fully-qualified field names, one rule per line.