Why Flow Beats Process Builder and Assignment Rules for Lead Routing
Salesforce Assignment Rules have been the default routing tool for years, but they come with hard limitations: no branching logic beyond criteria matching, no capacity awareness, and no easy way to incorporate multiple data points like industry, company size, and lead score simultaneously. Process Builder, now deprecated on the Salesforce roadmap, has similar constraints.
Record-Triggered Flows solve these problems because they support:
Decision elements that branch on multiple conditions simultaneously
Get Records elements that query related objects (like a custom Territory__c object or a rep availability flag)
Loop elements for round-robin logic across a queried list of users
Update Records elements that stamp the OwnerId, send an alert, and log a task in a single transaction
The result is a single, auditable automation that replaces a patchwork of rules, Apex triggers, and manual steps.
Mapping Your Routing Logic Before You Build
Jumping into Flow Builder without a routing map is the fastest way to create spaghetti logic you cannot maintain six months later. Before opening Salesforce, answer these five questions:
What defines a territory? Is it State, Country, a custom Region__c picklist, or postal code range?
What defines a lead tier? Is this your Lead_Score__c field, Einstein Lead Scoring grade, or a manually set Lead_Tier__c picklist (e.g., Hot / Warm / Cold)?
Who owns each territory-tier combination? Build a simple matrix: West + Hot → Jamie Chen; East + Hot → Marcus Rivera, etc.
What happens when the assigned rep is inactive or at capacity? Define a fallback queue (e.g., Unrouted_Leads queue).
Should the Flow fire on create only, or also on update? Routing on update lets you re-route when a lead score changes from Warm to Hot.
Document this as a simple table. It will become the direct input for your Decision element branches inside Flow Builder.
Step-by-Step: Building the Record-Triggered Flow
Step 1 — Create the Flow
Navigate to Setup → Flows → New Flow. Select Record-Triggered Flow. Set the object to Lead. Under "Configure Trigger," choose A record is created or updated if you want re-routing on score changes, or A record is created for new-only routing. Set the entry condition to run only when OwnerId = [Default Lead Queue ID] so the Flow does not re-trigger on records already owned by a rep.
Step 2 — Get the Lead's Territory Assignment
Add a Get Records element. Query your custom Territory__c object (or a custom metadata type if you prefer) where Region_States__c includes the lead's State field. Store the result in a variable called varTerritoryRecord. This lookup decouples your routing logic from hardcoded state values—when territories change, you update records, not Flow branches.
Step 3 — Build the Decision Element
Add a Decision element named "Route by Territory and Tier." Create outcome branches in priority order:
Hot + West: {!varTerritoryRecord.Region__c} = West AND {!$Record.Lead_Tier__c} = Hot
Hot + East: {!varTerritoryRecord.Region__c} = East AND {!$Record.Lead_Tier__c} = Hot
Warm + West: same pattern…
Default outcome: catches anything unmatched and routes to the fallback queue
Keep each outcome name readable (e.g., Hot_West) because you will reference them in downstream elements.
Step 4 — Assign the Owner
For each Decision outcome, add an Assignment element that sets a variable varAssignedOwnerId to the appropriate User ID or Queue ID. Use a formula resource or custom metadata to store User IDs rather than hardcoding them—this makes rep changes a metadata update, not a Flow edit.
For round-robin within a territory, add a Get Records element to retrieve all active users in a custom Territory_Member__c junction object, then use a Loop element combined with a counter variable to cycle through them using modulo logic on a custom Round_Robin_Counter__c field on the User object.
Step 5 — Update the Lead and Create a Follow-Up Task
Add an Update Records element to stamp OwnerId = {!varAssignedOwnerId} and set Lead_Routing_Timestamp__c = {!$Flow.CurrentDateTime} for auditability. Then add a Create Records element to generate a Task: Subject = "Follow up: routed lead", ActivityDate = TODAY + 1, WhoId = {!$Record.Id}, OwnerId = {!varAssignedOwnerId}. This ensures the rep sees the lead in their task list the moment it hits their queue.
Testing Your Flow Without Polluting Live Data
Never activate a routing Flow and test it in production. Use these three approaches:
Flow Debug mode: In Flow Builder, click Debug and provide sample field values. Walk through each Decision outcome manually to confirm branching logic.
Sandbox testing: Deploy to a full or partial sandbox. Create test Lead records with each territory/tier combination and confirm OwnerId updates as expected. Use the Flow Interview Log under Setup for a step-by-step execution trace.
Unit testing with a named credential: If you layer in Apex invocable actions later, write @isTest methods that cover each routing path and assert lead.OwnerId post-execution.
Written w help from Claude Ai