Einstein Case Classification
Einstein Case Classification is the Service Cloud feature that auto-predicts and populates picklist field values on incoming Cases.
Definition
Einstein Case Classification is the Service Cloud feature that auto-predicts and populates picklist field values on incoming Cases. Admins pick which fields to classify (Type, Reason, Priority, Sub-Type, custom picklists), Salesforce trains a per-field model on the org's historical Cases where the field was set, and the model fills the field on new Cases at create-time. Downstream routing, assignment rules, and reports run against the predicted values without waiting for an agent to read and categorize the case manually.
The feature is one of the longest-running Einstein for Service capabilities and pays back fastest on orgs with high case volume and consistent historical labels. It runs as a Salesforce-managed model with no per-org tuning required beyond field selection. The biggest source of disappointment is label inconsistency in the training data; teams that audit and standardize historical case classifications before turning the feature on get accurate predictions, while teams that skip the audit get the same inconsistency baked into every new case.
Why case classification is the easiest Einstein win when the labels are clean
Where Case Classification lives in setup
Setup, Einstein Service, Case Classification. The page lists every picklist field on Case eligible for classification. For each, you toggle classification on, pick the training data filter (record type, age, owner), and decide how the prediction surfaces (auto-set on save vs suggested for agent acceptance). The page also shows the historical record count for each field so admins can see whether the model has enough data to be useful before activating. Once active, predictions appear on new cases within minutes of save, and the Insights report tracks accept rate and accuracy over time.
Auto-set vs suggested mode
Two activation modes. Auto-set writes the predicted value to the field at case creation; the agent sees a categorized case from the start. Suggested mode shows the predicted value in a sidebar where the agent can accept or change it. Auto-set is the high-leverage mode because it lets routing rules run against the prediction without human intervention. Suggested is the cautious mode that builds trust before letting the platform write fields. The accept rate threshold for moving from suggested to auto-set is the same 85 percent rule that applies to Einstein Autofill; below that the field is too noisy for autonomous writes.
How the model learns from historical cases
The model trains on cases where the target field was populated. For Type, it looks at every historical Case where Type was set and learns which case text (subject, description, comments) correlates with each value. A minimum of 1,000 cases per Type value is the rule of thumb for reliable predictions on common values. Less than that and the value either never gets predicted or gets predicted with low confidence. Imbalanced training data (95 percent of cases are Type Support, 5 percent split across other values) produces a model that defaults to the majority value and rarely predicts the minority ones. Rebalancing through training data filters helps; rebuilding the picklist to use fewer values often helps more.
Label consistency: the make-or-break investment
Historical case labels often drift over time. A category called "Billing" in 2022 became "Billing Inquiry" in 2024. A Type value reps used loosely (Other) got applied to cases that should have been Type Returns or Type Refunds. Training a model on inconsistent labels produces a model that learns the inconsistency. The audit that matters: pull a sample of 500 historical cases per Type value, confirm each is correctly labeled, fix the ones that are not, then train. This work takes a week and is the single largest determinant of model accuracy. Skipping it produces a feature that works in suggested mode but fails in auto-set mode because the agents who built the auto-set expectations no longer recognize their own classifications.
Routing, SLAs, and the downstream impact
Case Classification's biggest indirect benefit is letting assignment rules and SLAs run on consistent values. Routing rules that depend on Type or Reason fire correctly on every case rather than only on cases where an agent classified before routing. SLA calculations that branch by Priority kick in immediately rather than after agent review. Reports group cleanly. The downstream effect compounds: a well-classified intake produces faster routing, faster SLA application, and cleaner reports, all from one feature that costs the team only the time to audit labels and turn it on.
Permissions, retraining, and audit
The Einstein Case Classification permission set grants agents access to predicted values in suggested mode. Without the permission, agents see the field empty even when a prediction exists. The model retrains automatically on a weekly cadence by default; admins can trigger immediate retraining after a labeling audit or significant data shift. Predicted values are written by the running user context (System for inbound cases, the agent for in-console cases). Record history shows the user, not "Einstein", which the audit team should know before sign-off. The Insights report surfaces accuracy by field and value over time, which is the diagnostic that catches drift.
Relationship to Einstein Bots, Agentforce, and Reply Recommendations
Case Classification predicts picklist values. Einstein Bots routes pre-case conversations to topics. Agentforce for Service handles entire conversations and can create or update cases. Einstein Reply Recommendations suggests reply text after the case is open. These four features serve adjacent moments in the service workflow without overlapping; Classification labels the intake, Bots and Agentforce handle deflection, Reply Recommendations speeds resolution. An org running all four sees compounded efficiency that no single feature delivers alone.
How to roll out Case Classification on a real org
The successful pattern: audit historical labels first, enable in suggested mode, pilot for four weeks, validate accept rate per field, switch high-accuracy fields to auto-set. The feature pays back fast on orgs with clean labels and never pays back on orgs that skip the audit.
- Audit historical case labels
Pull 500 historical cases per Type or Reason value. Confirm each is correctly classified. Fix mislabeled cases. The audit takes a week and is the highest-leverage step in the rollout.
- Confirm training data volume per field
Setup, Einstein Service, Case Classification. Check the training record count per field. Fields with fewer than 1,000 historical cases per value will produce noisy predictions; consider consolidating values or excluding the field from autoclassification.
- Enable Classification in suggested mode
Toggle classification on for the pilot fields. Mode Suggested. Wait for the model to train (usually under an hour).
- Pilot for four weeks and watch Insights
Pull the Insights report weekly. Watch accept rate per field per value. Catch values where predictions are consistently wrong; usually those are values whose historical labels were inconsistent.
- Switch high-accuracy fields to auto-set
Above 85 percent accept rate, auto-set is safe and unlocks the routing and SLA benefits. Below 85, leave in suggested or revisit the historical labels.
- Wire routing rules to use the predicted values
Once auto-set is live, update assignment rules and SLA branching to depend on the predicted Type, Reason, or Priority. The downstream value compounds when routing matches the predicted intake.
- Schedule the monthly Insights review
Pull Insights monthly. Track accuracy drift, especially on values whose underlying patterns shift seasonally. Trigger retraining when drift exceeds 5 percentage points.
Per-field toggle for which picklists Classification predicts. Common picks: Type, Reason, Priority, Sub-Type.
Suggested shows the value for agent acceptance; auto-set writes it on case create. Start with Suggested.
Record type, age, owner filters that scope the historical cases the model trains on. Useful when older cases used different labels.
Weekly by default; can be triggered immediately after a label audit or data shift.
Einstein Case Classification permission that gates agent visibility into predicted values.
- Inconsistent historical labels produce inconsistent predictions. The audit before activation is the highest-leverage step; skipping it produces a feature that never earns trust.
- Imbalanced training data (one value dominates) produces a model that defaults to the majority and rarely predicts the minority. Consider consolidating values or excluding the field.
- Auto-set mode without piloting suggested produces wrong values that flow into routing and SLAs. Validate accept rate before enabling auto-set.
- Predicted values write as the running user, not "Einstein". Record history does not flag Classification-written values explicitly.
- The 85 percent accept rate threshold is the right gate for auto-set. Below it, the feature creates downstream noise faster than it saves time.
Trust & references
Straight from the source - Salesforce's reference material on Einstein Case Classification.
- Einstein Case ClassificationSalesforce Help
- Set Up Einstein for ServiceSalesforce Help
- Einstein Service InsightsSalesforce 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 Classification do?
Q2. What's the value over manual classification?
Q3. What does the model need to train accurately?
Discussion
Loading discussion…