Einstein Case Routing
Einstein Case Routing is a Service Cloud feature that uses a trained classification model to predict the right queue, agent skill, or owner for an incoming case based on the case content and historical routing decisions.
Definition
Einstein Case Routing is a Service Cloud feature that uses a trained classification model to predict the right queue, agent skill, or owner for an incoming case based on the case content and historical routing decisions. The model trains on the case Subject and Description text plus selected related fields, learns the patterns that drove past routing assignments, and applies those patterns to new cases at creation or update time. The prediction lands on the case (typically as a recommended queue or skill) and feeds into Omni-Channel skills-based routing or a flow that performs the actual assignment.
Einstein Case Routing is one of a small family of Service Cloud Einstein features that automate the cognitive work of case intake. It pairs naturally with Einstein Case Classification (which fills Type and Reason fields), Einstein Case Wrap-Up (which drafts a closing summary), and Einstein Reply Recommendations (which surfaces draft responses to the assigned agent). Together the four features cover the lifecycle from case creation to closure, removing the manual sorting work that pulls agent time away from actual customer problem-solving.
How Einstein routes a new case to the right queue or agent
What the model learns from
Einstein Case Routing trains on the historical case dataset filtered to a recent time window (typically 12 months). The training pipeline reads each case's Subject, Description, and any additional fields the admin marks as features, plus the historical routing destination (queue, skill, agent). The model learns the patterns that distinguish a billing question from a technical support question from a refund request, and which routing destination matched each pattern. The prediction at runtime is the most likely routing destination given the new case's text and fields.
Data thresholds before the model can train
Like every predictive Einstein feature, Case Routing has published volume thresholds. At least 400 cases per routing destination across the training window, and at least 1,000 cases total. Below the threshold for a destination, that destination is excluded from the prediction set; the model still works for other destinations but cannot recommend the excluded one. Below 1,000 total, the model refuses to build. These thresholds protect customers from publishing a model that has not learned anything stable.
Wiring predictions into Omni-Channel routing
The prediction lands on a field on the case (typically a custom Recommended Queue or Recommended Skill picklist). Omni-Channel skills-based routing reads that field as the routing criterion. The actual assignment is performed by Omni-Channel, not by Einstein. This separation means Einstein can be enabled or disabled without rebuilding the routing logic, and the routing rules can incorporate other signals (region, priority, queue capacity) alongside the Einstein recommendation. Flow-based routing works the same way: read the Einstein field, decide assignment.
Confidence thresholds and the fallback
Einstein Case Routing returns a prediction with a confidence score. Above the configured confidence threshold, the prediction is written to the field. Below the threshold, the field stays empty (or is set to a fallback value) and the case routes by the standard rules. The threshold is a key tunable. Setting it too low lets shaky predictions drive routing decisions; setting it too high makes Einstein useless because most cases fall back. Start at 70 percent and adjust based on the team's tolerance for misroutes.
Refresh and feedback over time
The model retrains automatically on a weekly cadence by default. The retraining picks up new cases closed since the last training run and includes them in the next model version. This is the feedback loop that keeps the model fresh as the product, the team structure, and customer language evolve. Admins should review the published model card after each retraining to spot accuracy drops. A sudden drop usually signals a data shift (new product line launched, queue structure changed, recent case backlog) and may need a manual investigation.
The handshake with Einstein Case Classification
Einstein Case Classification and Einstein Case Routing solve adjacent problems and people sometimes confuse them. Classification fills the case Type and Reason fields (what is this case about). Routing predicts the queue, skill, or owner (where should it go). Many teams enable both: Classification first, then Routing using the now-populated Type and Reason as additional features. The combined accuracy is usually higher than either feature alone because Routing benefits from cleaner upstream labels.
When Routing recommendations go wrong
The most common failure mode is queue structure churn: routing destinations are renamed, merged, or split, and the model has stale labels. The fix is a model rebuild after the queue change. The second is concept drift from new product launches; the model has never seen the new product's vocabulary. Add a representative sample of recent cases mentioning the new product to the training set and rebuild. The third is over-reliance on Subject text; long, descriptive Descriptions usually improve accuracy more than tuning thresholds.
How to set up Einstein Case Routing
Setting up Einstein Case Routing is a guided build inside Service Cloud Einstein. The work upstream (clean historical data, stable queue structure) matters more than the build itself.
- Confirm volume against the threshold
Pull a count of closed cases over the past 12 months grouped by intended routing destination. Confirm at least 400 per destination and 1,000 total. Without the volume, the feature will refuse to build.
- Stabilize the routing destination set
Audit the queue or skill list. Merge duplicates, retire unused destinations, document the final list. Training a model on a queue structure that is about to change wastes the build.
- Run the Setup wizard
Setup, Service Setup, Einstein Case Routing. The wizard prompts for the target field (the case field the prediction writes to) and the feature fields (Subject, Description, and any custom fields).
- Build the model and review the model card
Launch the build. After completion, open the model card. Check overall accuracy and per-destination accuracy. If one destination has very low accuracy, the model may have insufficient examples for it.
- Wire the prediction into Omni-Channel or flow
Configure Omni-Channel skills-based routing to read the Einstein prediction field, or build a flow that branches on the field and assigns the case. Test with sample cases covering rich, sparse, and edge contexts.
The case field where the prediction is written. Typically a custom Recommended Queue or Recommended Skill picklist.
The case fields the model uses as inputs. Subject and Description by default, plus optional custom fields with predictive signal.
The minimum prediction confidence required to write the recommendation. Default starts conservative; tune based on misroute tolerance.
The historical period the model trains on. Default 12 months. Shorter windows react faster to change; longer windows give the model more data.
Default weekly. Sufficient for most teams; high-volume orgs may want daily refreshes if the data shifts quickly.
- Queue structure changes invalidate the model. Plan to rebuild after any queue merge, rename, or new addition.
- Per-destination accuracy can vary widely. A model that is 85 percent overall may be 95 percent on common destinations and 50 percent on rare ones.
- Confidence threshold set too low produces misroutes that erode agent trust. Start conservative; loosen only after observing the first round of accuracy data.
- Predictions are written at case creation or update. A case that already routed via standard rules will not retroactively re-route when Einstein later predicts a different destination.
- Long, descriptive Descriptions improve accuracy more than threshold tuning. Encourage agents and customers to provide context-rich case bodies.
Trust & references
Cross-checked against the following references.
- Einstein Case Classification and RoutingSalesforce Help
- Omni-Channel RoutingSalesforce Help
Straight from the source - Salesforce's reference material on Einstein Case Routing.
- Einstein Case ClassificationSalesforce Help
- Omni-Channel setupSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Einstein Case Routing do?
Q2. How does it differ from traditional assignment rules?
Q3. Where does Einstein Case Routing work best?
Discussion
Loading discussion…