Salesforce Implementation Strategies & Designs - Part 3

Part 3 (of 3): Case Classification to Quote

In Part 1 & 2, we reviewed the foundation for Case Types and their importance in the way that data moves from Source to Target. We discussed deterministic vs. probabilistic for structured and unstructured handling of data, we built a taxonomy and classifications, reviewed “Trust but Verify” and the importance of achieving ‘Clarity’ through Preparation documentation.

We also discussed Confidence as a probabilistic estimate of how certain the system is versus Correctness as a fact: for a given quote and a given, fixed version of the policy rules, the YES/NO either matches the rule-based outcome or it doesn't. There's no “60% correct,” the same way there's no “60% pregnant.”

We ended Part 2 with Source Systems and Project Experience reviews and a working strategy for the taxonomy process with 5 key components to follow as the foundation.

In part 3 of our Case Type Series we take things to the next level by leveraging semantic and generative systems for AI. This is not an easy concept to understand and I am breezing through things rather quickly but as I state in Part 1, I am not diving into the Agentic elements of AI and merely applying the key items to address our Case to Quote use case.

That said, I think its important to review some of the primary components and layers of AI before we move through the final part of the article: The Six Stages of the Pipeline (6).

Semantic vs Generative Systems:

I will be using Semantic and Generative systems in the case to quote flow so here is a quick overview to make sure the baseline is set.

·       Semantic Relating to meaning and structure. A semantic system maps inputs to a fixed set of known concepts or categories — classification rules, taxonomies, ontologies. It answers "what is this and how does it fit our known categories?"

·       Semantic maps to a Deterministic system where the same input always produces the same output, following a fixed, traceable set of rules. Repeatable and auditable by design you can point to exactly which rule fired and why.

·       Generative Relating to producing new content rather than selecting from a fixed set. A generative system (like an LLM) synthesizes an original response — a quote draft, an explanation — rather than matching an input to a predefined label.

·       Generative maps to a Probabilistic system where the output reflects likelihood rather than a guaranteed fixed answer, so the same input can produce varying outputs across runs. Flexible and better suited to ambiguity, but harder to trace and reproduce exactly.

·       How these four relate: semantic and generative describe what a system does (categorize vs. create); deterministic and probabilistic describe how reliably it behaves (fixed vs. variable).

·       In practice, a semantic layer is usually built to behave deterministically, and a generative layer is inherently probabilistic which is exactly why a confidence threshold (reviewed in Part 1) is needed to decide when to hand off from one to the other.

Agentic AI:

The Third category is Agentic AI which is Agentforce. Agentic AI can autonomously plan, reason and execute multi-step tasks to achieve a specific goal. That quote we are creating in our use case would be created by an Agent, not a human. Actually, the entire process would be done without a HITL. It goes beyond suggesting the next step. It plans, makes decisions, and takes action on its own using LLM (large language models) to understand the full context of the ask using memory, prompts (asks), history, supportive documents, past actions, templates, etc.

Layers in short:

• Semantic layer = find, rank, match. Uses Einstein Prediction and Data Cloud for grounding the data.

• Generative layer = draft and summarize. Use Einstein Generative features and this will fold into Agentforce.

• Agentic Layer = more complex top level orchestration. Agentforce sits on top of both with a heavier governance lift and relies on the ‘Trust Layer’ of Data Cloud for grounding and security.

• Note: Agentforce and Einstein are complementary, not competing.

The Six Stages of the Pipeline (6):

At a high level, every case moves through six stages:

We can revisit our case-to-quote workflow to provide a visual in our flow: a case record comes in, the system classifies it, scores its own confidence in that classification, hits a threshold (60%) and either drafts a quote automatically or routes the case to a human with the client always getting a final YES/NO on whatever quote reaches them. The client response will provide different actions to different teams.

1. Intake:

The case record enters the target system (Salesforce) with its defined attributes in each of the data sets of the source systems. The data must have required state of completeness at the point of entry or it will be rejected with an error and will not enter the system. This completeness is a non-negotiable.

2. Semantic classification:

Semantic Rules Layer does the classification and confidence scoring in #3 below - its the ‘verify’ layer providing deterministic, explainable data.

Deterministic rules or a trained model categorize the case. Declarative rules can include: flow decision elements, Validation Rules, or Assignment Rules in the business logic. Many of these can be if>then structure ("if Case Type = X and Amount > $10,000, classify as High Complexity").

Design note: rule is visible in the flow builder and the logic can be read by proper Salesforce access.

Use a  trained classification model like Einstein Prediction Builder (or a custom model via external services) if the classification is too vague and can’t be applied to an if/then structure. We have discussed unstructured data and a

Per our previous articles, start with declarative rules where classification logic is rule-based. Use a trained model only when patterns are too complex to manage manually. Per our discussions on structured (clean cut cases) and unstructured (vague/grey) data, in most cases you will use both deterministic and trained (or probabilistic).

Here are some examples to run through:

Semantic AI in SF:

• Lead/Oppty Scoring: Ranks records by likelihood to convert/close based on historic patterns.

• Case Classification & Routing (this articles focus): Matches incoming cases to categories, queues, or agents.

• Einstein Search: Semantic (vector) search across the entire CRM systems and its knowledge articles.

• Similarity/Next-Best-Action: Finds similar past cases or recommends next step from patterns.

Generative AI in SF:

• Case summarization: Drafts a summary of a long case thread

• Email/reply drafting: Writes a suggested response to a customer

• Knowledge article drafting: Generates draft KB articles from Case resolutions

• Call summarization: Turns call transcripts into structured notes.

Note: I’m not going through Einstein vs Data Cloud vs Agentforce vs Claude - just know for this article that for most enterprises Einstein, Agentforce and Claude are complementary. Agentforce, the agentic orchestration layer, sits on top of Data Cloud and Einstein. More on all this later.

3. Confidence scoring:

The system estimates how certain it is about that classification.

• Classification tells you what the case is.

• Confidence Score tells you how sure the system is about that classification

Design note: You will use Confidence_Score__c field (or something similar and keep it understandable) on the Case Object. It will be populated one of two ways:

• Use Einstein Prediction Builder, if you're using it for classification. It natively outputs a probability alongside the prediction.

• Use custom scoring logic, if you're using declarative rules for classification which will be built as a weighted score based on how many of your classification criteria were unambiguously met (grey or borderline areas will have an output via error record + notification + report).

• Design Note to Custom Scoring Logic: Teams will underestimate the work to create and maintain these rule-based Confidence classifications. May not be sustainable and will be replaced by more enhanced offerings from Salesforce acquisitions.

Design Note: Do not design to Outliers or you will set a bad precedence and mindset for future builds. Precedence refers to a legal, cultural, or historical decision that sets a rule or standard for future, similar situations, while a mindset is an individual's established set of attitudes, beliefs, and mental habits that shapes how they interpret and react to the world.

Precedence is an external rule established by history, whereas a mindset is an internal lens shaped by perspective. This should help to answer where bias comes from.

4. Threshold branch:

This is the decision point where a flow reads the confidence score and branches.

The confidence score determines whether the case proceeds automatically or gets routed to a human – HITL (human in the loop).

• Above threshold (>60%) → proceed to automated quote generation.

• Below threshold → route to a human for manual review and quoting.

Design Note: Be aware that the threshold for certain use cases may require more complex builds like multiple coordinated flows.

Design Note: It is best not to hardcode the threshold value in the flow as this would require a deployment (schedule) for updates and changes. As per the mention of jurisdictional changes, the updates may be an ongoing activity which, if hardcoded will create friction later. Look to use a Custom Metadata Type record, for example, rather than a hardcoded value in the Flow.

Threshold Number may give off two kinds of errors.

• False positive: a case gets auto-approved for quote generation when it shouldn't have (the classification was actually wrong). Cost: a bad quote reaches the client, damaging trust or creating rework.

• False negative: a case gets routed to a human when the system's classification was actually good. Cost: slower turnaround, human time spent on a case that didn't need it.

I bring these up as Trust is something that should be measured with the client. In our use case of Case to Quote/Invoice, a bad quote reaching a client is usually more impactful where expense is measured in the work involved to fix the trust that was broken. Know when to include HITL.

In this and other cases, a false positive will cost meaningfully more than a false negative.

5. Resolution:

Either a generative model drafts the quote, or a human handles it directly. Either way, the client gets a YES/NO checkpoint before anything is final.

Above threshold: generative quote drafting

Once a case clears the threshold, the quote itself gets generated. This is where the generative, probabilistic layer enters via Agentforce, (or a custom LLM call through External Services), invoked from the Flow.

A few implementation points worth designing in from the start:

• Constrain the output format. The generative step should populate specific fields on the Quote/Invoice record (line items, pricing, terms) rather than generating an unstructured block of text. This goes back to setting up the deterministic side and pulling in the probabilistic data to these standard components (templates, records, rules, etc) . This keeps the probabilistic layer's variability contained.

• Ground the generation in the case data, not general knowledge. The prompt should be built from the actual case record fields which come from deterministic components of output; pricing rules, product catalog, client history. The model is filling in a template with verified data rather than grey terms.

• Log the generation. This goes back to the question of “How did the system decide this?”. Store what was generated, when, and against which ruleset/model version, on the Quote record or a related object. This allows the resolution to be auditable despite being probabilistic. While you can't make the generative data itself deterministic, you can make it traceable.

The human ‘Client’ checkpoint: YES/NO

Regardless of which path a case took, the client sees the quote and makes a decision. This is your HITL - human-in-the-loop checkpoint, and it's non-negotiable in a "trust but verify" design.

Be sure to provide steps for the client to add reasons why it was rejected so that the error can be addressed and fixed. This also drives trust to let them know we are accountable and have a process to fix the issue. A simple ‘No’ is trouble. Use picklist values and a text field for additional information. A decline tagged "pricing too high" versus "wrong service entirely" tells you whether the problem was in the ‘generative drafting’ or the ‘classification stage’ further upstream. This tagging is what feeds the reconciliation process.

(The reconciliation process in Salesforce Agentforce, Einstein, Data Cloud -automates matching, verifying, and aligning data or transactions across different systems using AI agents and Natural Language actions.)

I would suggest providing the details of the new system to your clients, what to expect, the value to them - so that - when you hit a bump (trust) it does not damage the reputation of your company. They will give you leeway if you provide them with the roadmap you are on and the goals you are trying to achieve and that you will need a certain time frame to train the system. Be honest with your journey. People will understand.

Overview of the flow:

1.       Case created (intake)

2.       Classification (Taxonomy (part 2), Flow rules or Einstein model) > Case Type field

3.       Confidence scoring (native or custom) > Confidence_Score__c field

4.       Threshold check:

a.       Above threshold                     

b.       Below threshold

5.       Generative quote draft (or)

6.       Human review & manual quote

7.       Agentforce or External Services        

8.       Client YES/NO checkpoint

9.       Decision + reason logged

Every line item in this diagram is something you can point to in your org. That traceability is part of the Clarity we spoke about earlier. Clarity is King – it doesn’t just mean good preparation and document management. It runs through the entire project from beginning to end.  It answers the question "why did this case get this quote?" in an easy to trace and streamlined manner.

6. Action:

A system generated record or action is created. I used the Salesforce Field Service Platform scheduling/dispatch engine for the Case to Quote use case example. On YES acceptance, the client is provided with scheduling options to choose from for a technician team to begin work. These times are applied to the rules (hours of operation, staff availability, jurisdiction rules, asset availability, etc) of this particular client so the options are validated before being sent.

Your actions determined by the use case can be simple with just a notification, or complex requiring code and multiple parallel actions that drive out and into the target system. My projects usually require the later so be prepared to have a primary requirement to hold the sub requirements.

The END:

I hope you enjoyed this 3 part series.