Buyer's guide
How to evaluate Salesforce routing and orchestration software.
A guide for choosing routing software, and for spotting where routing ends and orchestration begins.
Dedicated routing tools are good at what they do. Round robin, load balancing, skills, capacity, availability. If assignment were the whole problem, one of them would be the whole answer. This guide covers the criteria that matter when routing is the pain, and the wider layer, intake, triage, execution, governance, that decides whether a routing tool is the whole answer or one part of it.
Built for: RevOps & Service leaders · Salesforce platform owners · Enterprise architects
Last updated: 11 July 2026
Answer first
Score two layers, not one.
The routing layer, round robin, load balancing, skills, capacity, availability, territory, and object coverage, is table stakes; most dedicated tools do it well. The workflow layer is where tools diverge: how work arrives (intake), whether it is triaged before routing, what happens after assignment, how AI is governed, whether one system serves sales and service, and the total cost of every tool involved. Evaluate a routing tool on the routing layer. Evaluate orchestration on the whole path.
Start here
Which situation is yours?
You are evaluating a routing tool.
Assignment is the pain today, and you want the best tool for it. Use the criteria below to score routing depth, ownership, native execution, and total cost, and to separate strong routing tools from the ones that assume vendor-led setup.
You suspect routing isn't the whole problem.
Work arrives by email, triage happens by hand, and something has to happen after assignment. The same rubric widens the frame to intake, triage, execution, AI governance, and cross-team reuse, so you can see where a routing tool ends and orchestration begins.
Criteria rubric
Ten criteria for evaluating Salesforce routing and orchestration software.
A neutral scorecard. The first three are the routing layer. The next six widen the frame to intake, triage, execution, AI, cross-team reuse, and cost. The last covers trial and proof.
| Criterion | What to look for | Where routing-only tools typically land |
|---|---|---|
| Routing depth | Round robin, load balancing, skills, capacity, availability, schedules, territory; across leads, cases, and custom objects; re-evaluation as conditions change, not just reassignment after elapsed time. | Usually strong. This is the product. |
| Ease & ownership | Can an ops admin configure and change routing without a deploy cycle or a support ticket, or are you buying a vendor dependency? | Varies widely. The better tools are ops-ownable; some assume vendor-led setup. |
| Salesforce-native execution | Routing runs inside the org, no external callouts for core logic, so pipeline data stays in your security and compliance boundary. | Varies. Some are fully native; some route via external services. |
| Intake | Does work get created from unstructured sources (email, any language), or only distributed once a record already exists? | Typically distributes existing records only. Intake is out of scope. |
| Triage before routing | Can routing act on intent, urgency, sentiment, and account context, read by AI, or only on the fields already on the record? | Typically none, or a single hard-coded field. |
| Execution after assignment | Approvals, escalation, enrichment, resolution, multi-step processes, handled in the same system, or stitched from Flows and manual work? | Out of scope. Ends at the handoff. |
| AI governance & control | Choose the model per step, deterministic control where certainty matters, a per-step audit trail, and a clear data boundary with the LLM provider. | Usually not applicable; little or no AI layer. |
| Cross-team reuse | One system for sales, service, and ops, logic configured once and reused, or one tool and one rule set per lane? | Often one lane; logic re-encoded per team. |
| Total cost of the stack | The routing licence plus every tool bought around it (intake, AI, integration) plus the manual effort on the seams. Per-seat/per-volume vs per-work-item, and how predictable it is as volume grows. | Low per-seat headline; the real cost is the stack and the seams, outside the quote. |
| Trial & proof | Can you install it and build a realistic scenario in a sandbox before signing? Named production references at your scale? | Trialability varies; a self-serve sandbox test is a good sign. |
Routing depth
What to look for
Round robin, load balancing, skills, capacity, availability, schedules, territory; across leads, cases, and custom objects; re-evaluation as conditions change, not just reassignment after elapsed time.
Where routing-only tools typically land
Usually strong. This is the product.
Ease & ownership
What to look for
Can an ops admin configure and change routing without a deploy cycle or a support ticket, or are you buying a vendor dependency?
Where routing-only tools typically land
Varies widely. The better tools are ops-ownable; some assume vendor-led setup.
Salesforce-native execution
What to look for
Routing runs inside the org, no external callouts for core logic, so pipeline data stays in your security and compliance boundary.
Where routing-only tools typically land
Varies. Some are fully native; some route via external services.
Intake
What to look for
Does work get created from unstructured sources (email, any language), or only distributed once a record already exists?
Where routing-only tools typically land
Typically distributes existing records only. Intake is out of scope.
Triage before routing
What to look for
Can routing act on intent, urgency, sentiment, and account context, read by AI, or only on the fields already on the record?
Where routing-only tools typically land
Typically none, or a single hard-coded field.
Execution after assignment
What to look for
Approvals, escalation, enrichment, resolution, multi-step processes, handled in the same system, or stitched from Flows and manual work?
Where routing-only tools typically land
Out of scope. Ends at the handoff.
AI governance & control
What to look for
Choose the model per step, deterministic control where certainty matters, a per-step audit trail, and a clear data boundary with the LLM provider.
Where routing-only tools typically land
Usually not applicable; little or no AI layer.
Cross-team reuse
What to look for
One system for sales, service, and ops, logic configured once and reused, or one tool and one rule set per lane?
Where routing-only tools typically land
Often one lane; logic re-encoded per team.
Total cost of the stack
What to look for
The routing licence plus every tool bought around it (intake, AI, integration) plus the manual effort on the seams. Per-seat/per-volume vs per-work-item, and how predictable it is as volume grows.
Where routing-only tools typically land
Low per-seat headline; the real cost is the stack and the seams, outside the quote.
Trial & proof
What to look for
Can you install it and build a realistic scenario in a sandbox before signing? Named production references at your scale?
Where routing-only tools typically land
Trialability varies; a self-serve sandbox test is a good sign.
Questions to ask
Nine questions for every routing and orchestration vendor.
Take these into every demo. The answers separate strong tools from tools that assume vendor-led setup, and routing from orchestration.
- 01
Can our operations team own it, or are we buying a dependency we call every time routing changes?
- 02
What is the real total cost, the licence plus the Salesforce edition, the tools around it, and the admin time to maintain it?
- 03
Does it run inside Salesforce, or does our pipeline data leave the org?
- 04
Can we trial it properly, install it and build our own routing scenario in a sandbox before committing?
- 05
Does it model how our team actually works, availability, capacity, and response time as routing inputs rather than afterthoughts?
- 06
What happens to work before it is routed? Who turns an inbound email into a record worth routing?
- 07
What happens after a record is assigned? Where do approvals, escalation, and resolution run?
- 08
How is AI governed? Which model runs where, what can it influence, and is every step audited?
- 09
Can one system cover both sales and service, or are we buying a tool per lane and owning the integration between them?
Fit check
When a routing tool is the right choice, and when it isn't.
A dedicated routing tool is the right choice when:
Records already exist and only need to be distributed. Assignment logic is the pain point; the workflow around it works. One team owns the routing lane, and cross-team reuse is not a near-term need. The vendor supports self-serve sandbox trials and named production references at your scale. Native execution and ops-ownable configuration are demonstrable, not just promised. Total cost, including anything you might buy around routing, fits the budget you actually have.
You are evaluating orchestration, not routing, when:
Work arrives from unstructured sources like email and someone triages it by hand. Assignment quality depends on intent, urgency, or account context that isn't already a field on the record. Approvals, escalation, enrichment, and resolution are stitched together from Flows and manual steps. Sales, service, and ops each want the same logic, encoded slightly differently, in different tools. You expect intake, AI triage, or multi-step processes to enter the picture in the next 12 to 18 months.
Where Ortoo fits
A Salesforce-native orchestration system, with routing as one step.
Ortoo Orchestrator is the orchestration side of this rubric. Q-assign handles routing inside the same system that turns inbound email into records (Email-to-Anything), triages with governed AI, and continues through approvals, escalation, and resolution. Pricing is per work item completed, and the system runs natively in your Salesforce org. If a dedicated routing tool is doing its job, it can keep doing it; Ortoo Orchestrator enters where the workflow around it strains.
Deeper comparisons
Ortoo Orchestrator vs routing point solutions
Where routing tools end and orchestration begins. Intake, triage, execution, and cross-team reuse compared side by side.
Read the comparison →Ortoo Orchestrator vs Agentforce
Two different jobs. What each is built for, where they overlap, and where they don't. A governance and control comparison.
Read the comparison →Ortoo Orchestrator vs building it yourself
Flows, code, and stitched integrations vs a Salesforce-native orchestration system. Total cost and ownership over 12 to 18 months.
Read the comparison →In production
What orchestration looks like at scale.
33,600
Hours reclaimed annually
168,000+
Cases processed annually
~100%
Routing accuracy
120,000+
Records processed in 3 months
16
Teams orchestrated, multi-language
Frequently asked questions
Buyer questions, answered.
What should I look for when choosing Salesforce routing software?
Score two layers. The routing layer, round robin, load balancing, skills, capacity, availability, territory, object coverage, is table stakes; most dedicated tools do it well. The workflow layer is where tools diverge: how work arrives (intake), whether it is triaged before routing, what happens after assignment, how AI is governed, whether one system serves sales and service, and the total cost of every tool involved. Evaluate a routing tool on the routing layer; evaluate orchestration on the whole path.
What's the difference between routing software and workflow orchestration?
A routing tool answers one question: who should get this record? Orchestration defines the whole path: how work arrives, how it is classified, who handles it, what happens next, under what conditions, and with what controls. Routing is one step in that path. Some Salesforce-native systems handle both in one place, with routing as a capability inside the orchestration.
Is native Salesforce routing enough?
For simple, criteria-based distribution, often yes, and it is already licensed. A dedicated tool adds round robin, load balancing, skills and capacity, availability and schedules, and rule changes without a deploy cycle. Orchestration adds the layer native routing and a routing tool both stop short of: intake, AI triage, and post-assignment execution. Which you need depends on whether assignment is the whole job.
How much should Salesforce routing software cost?
Compare total cost, not the per-seat headline. Factor in the Salesforce edition required, any minimum commitment, onboarding or services fees, the admin time to maintain the configuration, and the other tools you buy around routing (intake, AI, integration) and the manual effort on the seams. A low licence price with a heavy stack around it can cost more than a system that covers the whole workflow under one model.
How do I evaluate a routing tool before buying?
Insist on testing against your own routing reality, not a vendor's demo. Install it, build a realistic scenario in a sandbox, and watch it run before you sign. Push on the edge cases: the lead assigned to someone on holiday, the hot lead handed to a rep already buried, the SLA that only fires when someone is watching. And ask what happens to work before and after the routing step, because that is where the differences between tools become obvious.
Do I need orchestration if I only need routing today?
Maybe not today. If assignment is genuinely the whole problem, a dedicated routing tool is a reasonable choice. The question is the 12-to-18-month picture: when intake, AI triage, or multi-step processes arrive, teams tend to add a tool per problem and end up owning the seams. Evaluating for where you are heading, not only where you are, is the choice that ages best.
Can one tool handle both lead routing and case routing?
Some can, many can't. A lot of routing tools focus on one lane, revenue or service. If both matter, look for one system that runs lead routing, case handling, and custom-object workflows on the same model, so logic is configured once and reused rather than re-encoded per tool.
What questions should I ask a routing software vendor?
Can our team own it without a vendor dependency? What is the real total cost including the tools around it? Does it run natively in Salesforce or does our data leave the org? Can we trial it in a sandbox first? Does it treat availability, capacity, and response time as routing inputs? And the four the routing frame omits: what happens to work before it is routed, what happens after assignment, how is AI governed, and can one system cover both sales and service?
Take the next step
Map the workflow around your routing.
A workflow-mapping session covers how work arrives, how it's triaged and assigned today, what happens after assignment, and where an orchestration layer would take on the manual stretch.