Case Classification with AI: Options and Key Considerations

Option 1: Predictive Case Classification with Einstein

How it works: Uses a trained Machine Learning (ML) model to predict field values based on historical case data. When your model is active, Einstein predicts the value of every field selected in your model. The model re-trains over time based on agent feedback (acceptance/rejection). Human oversight is optional.
When to use: Classification taxonomy is relatively stable and not too large; historical case data is sufficient and high-quality for model training; no need for team-level or queue-level classification filtering.
Setup: Autofill Case Fields with Einstein Case Classification; Case Classification for Flows

Key considerations:

• Level of automation: You can control how much prediction automation you are comfortable with. There are three execution modes: recommended top values (less automated), select best value (more automated), and automate value (fully automated).
• Use in a flow: To fully automate case classification, add the Einstein ApplyCaseClassificationRecommendations action to your flow to apply case classification to predict field values for a case.
• Requirements: It is recommended to have a minimum of 1,000 cases in the last 6 months, ideally 10,000 cases for improved performance.
• Billing: Predictive Case Classification is included in Service Cloud and does not consume additional credits per case classified.
• Find more field volume and field type limitations in Considerations for Choosing Fields to Predict.

Option 2: Record-Triggered Flow + Prompt Template / LLM

How it works: A Record-Triggered Flow runs on case creation or case update, calls a Prompt Template via the Generate Prompt Response Flow core action, the LLM returns a structured classification result, Apex parses the JSON data returned by the Prompt Template, and the Flow writes classification fields back to the Case record. The same workflow can also be triggered from an agent action or during case escalation.
When to use: Automated, background classification triggered immediately after case creation or case update; classification taxonomy is manageable in size; no human oversight is required.
Setup: Using Prompt Builder, Flows, and Apex to Summarize and Classify Cases Faster

Key considerations:

• Accuracy: Ingest label descriptions alongside label values — not just the labels themselves — to improve classification accuracy. Output format should be structured JSON to allow reliable parsing. Include a Confidence Score as an optional signal but do not rely on it as a hard threshold; LLMs are not reliable at self-rating confidence.
• Prompt Chaining: For complex or hierarchical taxonomies, consider multi-stage prompt templates, and use a first stage to select the top-level Type, then a second stage to narrow to the correct Subtype within that Type. This reduces the number of options the LLM must reason over at each step and improves adherence to the classification hierarchy.
• Grounding: Do not hardcode the classification matrix in the prompt. Store values in a Custom Object or Custom Metadata Type and merge them dynamically into the prompt. Classification options can also be stored as records in Data Cloud, indexed via a Search Index (Data Library + Retriever), and used to semantically narrow the classification list before the LLM makes a final selection. See Agentic RAG with Advanced Data Cloud Setup for a reference implementation.
• Billing: Each prompt invocation consumes Flex Credits. Credit consumption scales directly with case volume and the token size of the classification prompt. Credit consumption will depending on your specific licensing model. Use a guard condition in the Flow to ensure the prompt only runs when no classification has already been accepted, to avoid re-running and consuming credits unnecessarily.

Example Prompt Template Pattern:

You are an expert AI classification assistant. 
Analyze the case and determine the core reason for contact.

### Classification Table (merged dynamically into the prompt)
| Type         | Subtype         | Description                                |
|--------------|-----------------|--------------------------------------------|
| Billing      | Invoice Request | Customer wants a copy of a past invoice... |
| Tech Support | Login           | Customer is locked out...                  |
...

### Instructions
1. Read the case content carefully.
2. Select the single best-matching Type and Subtype.
3. If insufficient context, output "Uncategorized" for both.

### Output Format
Return ONLY valid JSON:
{ "Type": "...", "Subtype": "...", "Confidence_Score": [1-10] }

### Input
{!$Input:Case_Description}
{!$Input:Case_Subject}

Option 3: Non-RAG Search Index — Majority Vote Classification

How it works: Rather than using a Large Language Model to select the best classification, this approach uses the semantic search capability of the Data Cloud Search Index as a pure signal — no generative AI is involved. A Record-Triggered Flow fires on case creation and calls an Apex class. The Apex class executes a Data Cloud Query against the Case Search Index, passing the new case's Subject and/or Description as the search string. The query returns the top N semantically similar historical cases, including their classification fields (e.g. Type, Sub_Type__c). The Apex code then performs a majority vote — tallying the most frequently occurring classification values across the returned results — and writes the winning values directly back to the triggering Case record. No prompt template, no LLM call, and no Einstein Request credit is consumed.
For full details on this approach, see Agentforce and RAG: Best Practices for Better Agents (Section 13.3: Non-Generative Use Cases).
When to use: Classification taxonomy is stable and well-populated in historical data; LLM credit consumption needs to be minimised or avoided entirely; real-time, synchronous classification is required but generative AI is not approved or not available; a "most common answer wins" heuristic is acceptable as the classification logic.

Key considerations:

• No LLM involvement: Classification is determined purely by frequency analysis of semantically similar cases — the system applies the most common Type/Sub_Type__c from the top N results. This is deterministic and reproducible, unlike an LLM, but it cannot reason over ambiguous inputs or handle edge cases gracefully.
• Data quality is critical: Because the majority vote relies entirely on the classification values attached to historically similar cases, poor data hygiene directly degrades accuracy. Cases with missing, incorrect, or inconsistently populated classification fields will distort the result. Apply a retriever filter (e.g. Status = Closed, or a custom Classification_Reviewed__c = true flag) to restrict the search to high-quality, validated records.
• Search Index configuration: Case data is ingested into a Data Model Object (DMO) in Data Cloud. A Search Index is configured against the Case DMO — key text fields (e.g., Subject and Description) are selected as fields to chunk and vectorise. Classification fields (e.g., Type) must be registered as additional/filter fields at the Search Index level so they can be queried using a Data 360 vector search query via Apex code.
• Billing: Because no prompt template or LLM is invoked, this approach consumes no Einstein Request credits. It does rely on Data Cloud Search Index infrastructure and the associated data ingestion pipeline. Data Cloud Query credits are consumed each time the Apex class executes, scaling with case volume.
• Accuracy trade-off: Accuracy must be assessed against the customer's specific case data and taxonomy. The approach performs well when similar cases have consistent, high-quality classifications; it degrades where case descriptions are ambiguous or the taxonomy is large and granular.
• Tie-breaking: Implement an explicit tie-breaking strategy in Apex (e.g. select the classification with the highest average similarity score among tied candidates, or default to "Uncategorised") to avoid non-deterministic behaviour when two values appear with equal frequency.

Option 4: Data Cloud AI Model Builder

How it works: A custom Machine Learning (ML) classification model trained and hosted in Data Cloud. With AI Models, you can use multi-class classification to predict the likelihood that records fall into one of 3 to 50 buckets. Training data is ingested into Data Cloud, a model is trained in the AI Models tab using Data Cloud compute, and predictions are surfaced via Flow integration or Predict API.
When to use: A custom ML model with full control over training data and features is required; large-scale classification needs where a rules-based or generative approach is impractical.
Setup: Classification with Data Cloud; Multiclass Classification; Topic Classification; Use Outputs from Predictive Models

Key considerations:

• Setup and maintenance: Creating, optimising, and maintaining custom AI models requires significant data engineering effort and ongoing oversight.
• Business Process: The model generates a prediction which can be actioned within any automated or manual business process (Flow, Apex, Predict API). On-demand predictions aren’t persisted anywhere unless done so manually. When activating a predictive model, a custom invocable action is automatically created for that model so it can be used in flow. The same custom invocable action can also be executed within Apex using the Invocable namespace. For Flows, connect any data that’s accessible within a flow to a predictive model and generate on-demand predictions and prescriptions.
• Billing: Data Cloud AI Model Builder consumes Data Cloud credits for model training and batch scoring runs. Credit consumption depends on data volume and scoring frequency.

The table below provides an overview of the available options. When selecting an approach, consider additional factors such as retrieval latency, maintenance effort, credit consumption, and the limitations documented for each option.