Territory-driven routing with Fullcast

Fullcast routing is powered by your territory plan. Instead of rebuilding go-to-market rules in a separate system, routing policies read directly from your territory structure, coverage assignments, and team configurations. When you make changes in your territory plan—reassigning reps, restructuring segments, or updating coverage—routing automatically reflects those changes without requiring manual updates.

In this customer office hours session, we discussed how territory-driven routing works, walked through account, lead, and opportunity routing scenarios, and explored the architecture that connects Fullcast policies to Salesforce. Click on the timestamps below to jump to each video section, or refer to the corresponding section below for a summary.

Section Timestamps

• Introduction & Context 0:00

• The Big Idea: Why Territory-Driven Routing? 4:22

• What Is a Routing Policy? 10:50

• The Salesforce Flow: Triggering Routing 13:30

• Policy Hierarchy: Where to Build Policies 23:10

• Account Routing Scenarios 19:50

• Lead Routing and Best Matched Account (BMA) 39:50

• Opportunity Routing Scenarios 52:40

• Auditing with Policy Status Records 48:10

• Resources & Final Thoughts 56:00

The Big Idea: Why Territory-Driven Routing? 4:22

Traditional routing approaches require RevOps teams to define go-to-market rules in one system (a spreadsheet, a planning tool, or a territory plan) and then rebuild those same rules again in Salesforce or a separate routing tool. This creates two problems:

• Duplicated work: Every rule exists in two places, and both must be maintained independently.

• Lag between planning and execution: When someone leaves the business, gets promoted, or a territory is restructured, the routing rules don't update until someone manually makes the change—often days later.

Fullcast routing eliminates both problems by reading directly from your territory plan. When you update coverage—even with a future-dated change—routing automatically follows. One customer went over a year without touching their routing configuration despite ongoing territory changes, promotions, and new hires. The routing simply worked because it was always reading from the current state of the territory plan.

What Is a Routing Policy? 10:50

A routing policy defines what should happen when a specific event occurs on a Salesforce record. There are three important concepts to understand:

1. A Policy Requires a Trigger

Routing policies execute in real time, fired by a specific event—such as a firmographic change on an account, a new lead being created, or an opportunity reaching a certain stage. This is different from the scheduled nightly export that syncs your territory assignments to Salesforce.

2. Real-Time Routing vs. Scheduled Export

Your scheduled export (typically nightly) pushes territory assignments from Fullcast to Salesforce on a cadence. Routing policies handle the real-time, event-driven scenarios that can't wait for the next scheduled sync—such as routing a new inbound lead immediately or reassigning an account the moment it flips from prospect to customer.

3. Common Policy Types

The Salesforce Flow: Triggering Routing 13:30

Fullcast routing is triggered by a Salesforce Flow rather than an Apex trigger. This is a deliberate architectural choice with important implications:

• Lightweight execution: Unlike Apex triggers (used by many routing tools) that fire on every single edit to a record, a Flow only fires when your specific entry criteria are met. This is critical for mature Salesforce orgs with heavy automation on core objects like Account or Lead.

• Precise control: You define exactly when routing should run—for example, only when the employee count field changes, or only when the record type flips from Prospect to Customer.

• One flow per object: A best practice is to maintain a single routing flow per object (one for Accounts, one for Leads, one for Opportunities). Within that flow, use decision elements to branch into different routing scenarios based on what changed. This simplifies maintenance and avoids the performance issues that come from multiple flows triggering on the same object.

Note

For teams that prefer to keep their Salesforce flows simple, Fullcast also supports a tagging approach. Instead of building decision trees in the flow, you send all relevant data fields to Fullcast and let the routing engine evaluate the decision logic based on your policy configuration. This keeps the flow lightweight and moves the routing logic into the Fullcast UI, where RevOps teams can manage it without editing flows.

Policy Hierarchy: Where to Build Policies 23:10

Routing policies are associated with specific levels of your territory hierarchy. Understanding where to place them is one of the first and most important decisions when configuring routing.

How Policy Matching Works

When a routing event fires, Fullcast first evaluates your territory rules to determine where the record belongs in the hierarchy. For example, an account with 10,000 employees in California might resolve to All Companies → NAMER → Enterprise → Enterprise West.

Once the territory match is found, Fullcast looks for a matching policy at that level. If none exists, it walks up the hierarchy until it finds one. This means:

• Build policies at the highest level where the rules are the same. If every segment handles firmographic re-routing identically, place that policy at the top level (e.g., All Companies). You only need segment-specific policies when the routing behavior genuinely differs.

• Fewer policies = less maintenance. The more you can abstract policies upward, the fewer you need to manage.

Watch for Broken Rules

A common pitfall occurs when a policy is built at a low level in the hierarchy, but a parent node above it has no territory rule. Because the routing engine evaluates through your territory rules to reach the policy, a missing rule at any intermediate level means the system cannot traverse down to the policy. Always ensure your territory rules form a continuous path from the top of the hierarchy to the level where your policy is built.

Account Routing Scenarios 19:50

Account routing handles real-time changes to account records that require immediate reassignment. Three common scenarios illustrate how this works:

Firmographic Change (e.g., SMB to Mid-Market)

When a data field like employee count updates on an account, the routing flow fires and sends the updated firmographic data to Fullcast. The engine re-evaluates the territory rules to determine where the account now belongs and assigns it accordingly. This is the most common account routing scenario.

Prospect-to-Customer Flip

When an account's record type or status changes from Prospect to Customer, routing can immediately assign the appropriate CSM. Using role-based routing, the policy looks at the matched territory and finds the person assigned to the CSM role. This single policy can serve your entire go-to-market because it dynamically reads from your coverage assignments.

Holding Pen Assignment

Many organizations maintain far more accounts than their reps can actively work. Unassigned accounts sit in a "holding pen" until an engagement signal—such as a white paper download or demo request—triggers routing. When that signal fires, the policy uses a round robin to distribute the account fairly among the reps covering that territory.

Round Robin and Smart Plan Territories

For territories built using Smart Plan, routing uses round robin rather than re-running the Smart Plan balancing logic. This prevents a single rep with a lighter book from being inundated with every inbound account. The round robin cycles through the child territories (e.g., Enterprise West 1 through West 5) and assigns to the account executive in each. If a territory contains a TBH (to-be-hired) placeholder instead of an active rep, routing skips it and moves to the next territory in the rotation.

Lead Routing and Best Matched Account (BMA) 39:50

Lead routing follows the same territory-driven logic as account routing, with one critical addition: the Best Matched Account (BMA) stage.

Why BMA Matters

In Salesforce, leads are not natively related to accounts—the company name is just a text field. But to route a lead correctly (for example, to the AE who already owns the Accenture account), you need to determine whether a matching account already exists.

The BMA stage uses configurable matching rules to find the best existing account match for an inbound lead. When a match is found, Fullcast stamps the account ID into a BMA lookup field on the lead record. The routing policy can then use this relationship to route the lead based on the matched account's territory and coverage—sending it directly to the assigned AE, BDR, or CSM rather than treating it as an unmatched inbound.

Routing Leads Twice

A useful pattern for some organizations is to route a lead twice during its lifecycle:

1. First route (lead creation): The lead is routed to a BDR/SDR for qualification. At this stage, data quality is uncertain—the person may have used a fake email, or the interest may not be genuine.

2. Second route (after qualification): Once the BDR validates the lead as a real, interested person, the lead is re-routed to an AE—still as a lead, not yet converted. The AE then confirms the opportunity before conversion to Account/Contact/Opportunity.

This two-stage approach prevents junk data from polluting your Account and Contact objects. Whether this pattern is right for your organization depends on your sales process and the maturity of leads at the BDR-to-AE handoff point.

Opportunity Routing Scenarios 52:40

Opportunity routing triggers actions based on changes to opportunity records, typically to engage additional team members at the right moment in the sales cycle.

Sales Engineer Assignment

When a deal reaches a certain value threshold, a routing policy can automatically assign a sales engineer from a team configured in the Teams module. The policy uses a round robin across the available SEs and adds the selected engineer to the opportunity team. This ensures SE coverage scales with deal complexity without manual intervention.

Early CSM Engagement

Rather than waiting for the prospect-to-customer flip on the account, some organizations trigger CSM assignment when an opportunity reaches a late stage (e.g., Negotiation or Commit). This allows the CSM to begin building a relationship and gaining context before the deal closes, improving the customer onboarding experience. The routing policy round-robins across available CSMs and adds them to the opportunity team or account team.

Auditing with Policy Status Records 48:10

Every routing execution creates a Policy Status record in Salesforce. This record provides a complete audit trail organized into three sections:

Policy Status records are invaluable for answering questions like "Why did this route to that person?" and for demonstrating to sales leaders that round robins are distributing fairly. The territory routing input section serves as a roadmap: start at the top of your rules, follow the data through each evaluation, and trace exactly how the record arrived at its destination.