Rules of Engagement: how Default decides which queue or owner gets a lead

Rules of Engagement in Default is a reusable ruleset that decides who owns an inbound lead. Each rule checks the lead’s data, and the first rule that matches sends the lead to a queue, a specific user, or no one. You build the ruleset once in the Routing app, publish it, and run it from any workflow with the Rules of Engagement node. When a rule sends a lead to a queue, Default also picks the queue member with the queue’s routing policy. Default records every evaluation, so you can see which rule decided and why the rules above it did not.

​

Rules of Engagement at a glance

Every Rules of Engagement decision in Default follows the same steps:

1. A workflow reaches the Rules of Engagement node. Any trigger can start the workflow, for example a form submission or a new CRM record.
2. Default fills the ruleset’s inputs from data earlier in the workflow, such as the trigger’s CRM record or an Enrich Data result. There is no mapping step.
3. Rules run from top to bottom. The first rule whose criteria match decides. Default does not check the rules below it.
4. The rule routes the lead to a queue, a user, or no one. For a queue, the queue’s policy picks 1 member.
5. The workflow continues on Resolved or Else. Later nodes use the resolved user, for example to set the CRM owner, notify the rep, or show a scheduler.
6. Default logs the evaluation: the inputs it received, every rule it checked, and the result.

​

When to use Rules of Engagement

For worked territory and qualification designs, see Territory and segment routing and Qualifying inbound leads.

​

Sources and inputs

A ruleset reads only the fields you declare on it. On the ruleset page, select Manage sources to open Inputs. Select Add source, then Add field under each source, and select Save inputs. Only CRMs that are connected and healthy appear under Add source. The workflow fills each input automatically from the matching data that is guaranteed to exist before the Rules of Engagement node. If several earlier nodes return the same object, Default uses the most recent one. An input with no matching data stays empty. How inputs affect evaluation:

• An empty input counts as a blank value. Default still checks every rule in order, and each condition treats the blank value the way a Multi-Branch condition does. A condition such as equals, is any of, contains, or a number comparison is false. A negative condition such as does not equal or is not any of is true.
• Check that the value exists when a rule needs it. For example, a rule that matches Country is not any of United States and Canada also matches a lead with no country. Add a condition that Country exists to stop that. The operator reads exists on enrichment, form, and event inputs, is not NULL on Salesforce fields, and is not empty on HubSpot fields. Those CRM labels are the same saved check. It matches a stored value. It rejects a missing value, a HubSpot empty string, and an empty multi-select.
• A value of the wrong type counts as empty, for example text in a number input. The log marks the input Type mismatch.
• An owner field is converted to a Default user. Default looks up the CRM user ID in each person’s integration mapping in Settings → Users. An unmapped ID counts as empty, and the log marks the input Could not map to a workspace user.

If you change the type of an input that a rule uses, or remove its source, the editor warns you. Conditions written for the old input stop matching until you rewrite them.

​

How a ruleset evaluates rules

Rules in Default run from top to bottom, and the first match wins. Put narrow rules above broad ones. Default never checks a rule below the one that matched, even when that later rule would also match. Each rule has 4 parts, edited in the rule drawer: Select New rule to add a rule at the bottom of the list. Drag a rule by its handle to move it. Reordering is off while Search rules has text in it, so a move never jumps rules you can’t see. When no rule matches, the ruleset is unresolved. The workflow takes Else, or uses the step’s Fallback queue when one is set.

​

Route to a queue, a user, or no one

A User target does not go through a queue, so it never counts toward a queue’s round robin.

​

Rule fallback and the step’s Fallback queue

Rules of Engagement in Default has 2 fallbacks that apply at different times:

• A rule’s Fallback applies when the rule matches and its User target can’t be used. A Queue target always counts as resolved at the rule level, even when the queue has no eligible member, so a rule that routes to a queue never uses its fallback. No one is not available as a fallback.
• The step’s Fallback queue, set on the workflow node, applies when the ruleset runs and resolves no owner: no rule matched, or the matching rule’s target and its fallback both failed. The workflow takes Resolved with that queue, but Default does not pick a member from it.
• Neither fallback applies when a rule routes to No one, or when the ruleset can’t run at all, for example because it was deleted.

For a workflow that must set an owner, handle Else yourself, for example with a Round-Robin node on a catch-all queue. Use Fallback queue only when a later node needs the queue itself.

​

What the workflow receives from Rules of Engagement

In the data picker, the Rules of Engagement folder holds Latest resolved user, the user from the most recent Rules of Engagement node. Pick it for an owner field, a Slack message, or a scheduler host. The node also sets Latest queue whenever it resolves a queue. Resolved can arrive without a user: when the matched queue has no active members, or when the step’s Fallback queue applied. Before an owner write or a Display Scheduler that needs a person, add a Multi-Branch node that checks Latest resolved user exists, and send the rest to a catch-all path. Matched Rule holds the rule that decided. In a Multi-Branch condition, the value picker lists the ruleset’s rule names, so you can send each rule’s leads to a different action. Default stores the rule’s ID, so renaming a rule keeps the condition working. The node also returns the matched rule’s name for messages.

​

Drafts, publishing, and versions

• Every edit saves as a draft. The ruleset’s badge reads Draft before its first publish, Draft changes when it has unpublished edits, and Published when every change is live.
• Publish creates a new version. Workflows always run the latest published version, so you do not need to edit them after you publish.
• Only published rulesets appear in the Ruleset field of the workflow node.
• Publish stays unavailable until the ruleset has at least 1 rule and every problem listed on the page is fixed.
• The evaluation log records the version that made each decision.

​

Example: route inbound Salesforce leads by region and company size

This example builds 1 ruleset for a workflow that starts when Salesforce creates a Lead. It uses 2 standard Lead fields, Country and Number of Employees:

• Large leads from EMEA (Europe, the Middle East, and Africa) go to a member of the Enterprise EMEA queue.
• Other EMEA leads go to a member of the EMEA Growth queue.
• Every other lead takes Else, where a catch-all queue picks the owner.

Before you begin:

• Connect Salesforce in Settings → Integrations.
• Create the Enterprise EMEA, EMEA Growth, and Global Inbound queues.
• Give each queue members and a routing policy that includes Objects in Assignment Units.
• Map each queue member to their Salesforce user ID in Settings → Users.

​

Create and publish the ruleset

​

Use the ruleset in a workflow

​

Test the complete route

​

Review a routing decision

Every Rules of Engagement evaluation in Default is logged. Open the ruleset and select the Logs tab. The table lists evaluations from the last 7 days, newest first, 50 at a time. Select Load more for older rows in that window, and use the table controls to search, filter, sort, and pick columns. Select a row to open the evaluation:

• Resolved member: the person the lead went to, when there is one.
• A summary with Outcome, Matched rule, Source with a link to the workflow run, and Version.
• Inputs: every declared input and the value it received, plus any input problem, such as Type mismatch or Could not map to a workspace user.
• Rules: every rule of the evaluated version, in the order Default tried them. The rule that decided shows Matched, and rules below it show Not executed. Each checked rule shows its conditions with a TRUE or FALSE result.

A workflow run shows the same breakdown to admins. In the run’s Run Details, the Rules of Engagement step links to its evaluation with view evaluation, and it expands to show the rules inline. See Why a lead went to a rep for the full trail across workflows, queues, and assignments.

​

Fix an unexpected Rules of Engagement result

Related: Lead routing software from Default