Setting up a lead assignment rule looks simple in Setup, but the configuration choices ripple through the entire sales pipeline. Get the entry order right, pick the right assignment target (user versus queue), set the notification template, and test every path before activating. Build in a sandbox with realistic Lead data, not synthetic test records.
- Map the routing logic on paper first
List every team that should receive Leads and the criteria that identify their territory or segment. Order the criteria from narrow to broad, ending with a catch-all that routes unmatched Leads to a triage queue. This sketch becomes the entry order in the rule.
- Create the assignment rule
Setup > Lead Assignment Rules > New. Name it descriptively (Standard Lead Routing 2026, not Rule 1). Each org has only one active rule, so the name should reflect the current routing strategy.
- Add rule entries in priority order
For each entry, set the order number, criteria (field comparisons or formula), assignee (user or queue), and email template. Most teams place narrow criteria first and broader fallbacks below. The platform evaluates top-down and stops at the first match.
- Configure the catch-all entry at the bottom
Add a final entry with no criteria (or always-true formula) that assigns to a triage queue. This guarantees no Lead falls through to the default owner. The triage queue can re-route manually or trigger Flow logic to retry assignment.
- Set the active flag on the rule
Only one assignment rule per object can be active at a time. Activating a new rule deactivates the previous one automatically. Confirm the deactivation does not orphan in-flight routing logic before flipping the switch.
- Enable Use Active Assignment Rule on intake paths
For Web-to-Lead, check the box in the Web-to-Lead settings. For API inserts, set the AssignmentRuleHeader option in the call. For manual UI creation, the prompt appears automatically; train sales ops to check it consistently.
- Test every entry path in sandbox
Create test Leads matching each entry criteria. Confirm the Lead routes to the expected owner, the email notification sends, and no entries are accidentally short-circuited by entries above them.
- Build the post-activation monitoring report
Report grouped by Owner, filtered to Leads created in the last 7 days. Look for unexpected concentrations on the default owner or on a single user, both of which indicate the rule is not firing as expected.
Priority order of rule entries. The platform evaluates top-down and stops at the first match. Order is the single most important config choice.
Who owns the Lead when the entry matches. Queue assignment is more flexible than direct user assignment because queue membership can change without editing the rule.
The template for the notification email sent to the assignee. Different templates per team let you tailor handoff language by audience.
- Only one Lead Assignment Rule can be active at a time. Activating a new rule auto-deactivates the previous one, which can break routing if the new rule is incomplete.
- Entry order matters absolutely. A broad criteria entry placed above narrow entries short-circuits the narrow ones, and the Lead routes to the wrong team. Order from narrow to broad.
- Editing an existing Lead does not re-fire the assignment rule by default. To re-route on edit, build a Flow that calls AssignmentRuleHeader.useDefaultRule = true on update.
- The native engine does not support round-robin. Equal distribution across team members requires a Flow with a counter field or an AppExchange package like LeanData.
- Misrouted Leads fail silently. Build the post-activation monitoring report on day one because misrouted Leads do not generate complaints, they just sit unworked.