Salesforce Implementation Strategies & Designs

Salesforce Implementation Strategies & Designs

Part 1 (of 3): Introduction, Use Case and How AI is supported.

Introduction

For most of my career, my job has been designing how a business process actually runs in Salesforce. How a Case moves through Service Cloud, how a Lead becomes an Opportunity and an Opportunity becomes a Work Order. Lately, that job has picked up a new component: AI. Not as the subject of the project, but as one more piece I have to design for, the same way I'd design for an integration, an approval process, or data migration.

This series is about that. How an implementation strategist designs for AI inside a Salesforce project, without pretending to be a data scientist. I'm not going to teach you how a model is trained or how to tune a prompt. I'm going to walk through the actual questions I ask, the actual scenarios that blow up a timeline, and the actual architecture decisions that determine whether an AI-assisted process is trustworthy enough for a client to sign off on.

I was going to write a simple article on a use case for Case to Quote/Invoice, with a threshold that automatically branches to the customer for a YES/NO response, or to a human checkpoint if it falls under that threshold. Then the real-life scenarios I've hit in the design phase pulled me sideways, the part of the project where you ask the real question: “is this possible, given our timeframe, our finances, our historical data and current metrics, our 7 source systems, our record data, our metadata, our processes?” Here's why that question matters more than it sounds like it should and why this has become multiple articles.

Are Case Types Mature Enough to Use?

Before you can design a threshold, a branch, or a confidence score, you need to know what you're actually classifying. So, the first question I ask on any of these projects is: are Case Types (or whatever the equivalent object is) mature enough to build on?

Here's a real scenario which I recently came across: there are no Case Types. Only one, used for everything. What then with no historical data to reference?

Here's another real one: there are Case Types, but the actual routing is done by tribal knowledge. The email came in from Jane, so Sally and Jake are the only two people who know it's an order — because Jane works in operations, and they happen to know which account she's currently working.

Houston, we have a problem.

These scenarios apply just as easily to Leads in Sales Cloud, to Marketing Cloud journeys, or to any of the other use cases I'll get to later in this series. I'm using Service Cloud & Field Service Case Types here because the real scenarios I've lived through recently are on this platform, and because this particular case; Case to Quote/Invoice, touches quotes, invoicing, warranties, and a full team of downstream complexity that makes it a good stand-in for the kind of project you'll actually be asked to design.

Historical Data or Not

If there's usable historical data in your Case Types (or Leads, Opportunities, whatever the object is) that’s an excellent start. If there isn’t, as in either Case scenario above, you don't have records to work, map or train from.

You'll need to create the taxonomy and training data before you can design anything on top of it. That's not a technical problem. That's a scope and timeline problem, and it's yours to flag before anyone starts talking about automation.

Taxonomy vs Classification:

Before I move on its important to know for this article what the difference is between Taxonomy and Classification and why I mention that creating a taxonomy is a key part of this process.

Classification assigns an item (ie. Case support ticket) to a specific, functional group based on pre-defined operational criteria like a operational bucket or routing rule. (e.g., "Billing Dispute" or "Priority 1 Incident")

Taxonomy builds the entire hierarchical framework of relationships and parent-child categories that define what the case types actually are. It maps out primary categories, subcategories, and granular case types (e.g., Billing > Invoice Error > Duplicate Charge).

We are after the taxonomy or the hierarchy model of the Case Types and from there we classify what path it takes for resolution. This path can be a Salesforce flow that triggers an action like routing a record to a queue or User, sending alerts, creating follow up tasks or calling an Apex Action or External Service (such as notifying a third-party billing platform via API).

"Trust but Verify"

Let's talk about “trust but verify” in an AI-assisted business process. Notice I say assisted, not new but assisted or supportive. You're typically not overhauling a primary process that already involves source-to-target systems integrations, Service Cloud, CPQ, and so on. You're identifying where, inside an existing process, AI creates ROI you can prove.

When teams are asked to “improve a process, with AI” it can be approached as a redesign (what steps can be removed, merged or automated) rather than just “find the part of the process step to insert AI.” If you just start swapping out process steps for AI there will be missed opportunities for ROI.

You don't have a year to prove that ROI. You may have a quarter, if you're lucky. That's your runway. An MVP that produces real metrics - proof that additional resources, finances, and timeline can be justified - is what gets you to the next phase. Providing quick wins and additional value adds provides more support for your next MVPs. The more preparation you do up front, the more grace you get when you hit the speed bumps and don't forget the startup costs and timeline - in dollars - that always surprises everyone.

"Milestones and Measures"

So how do you get from “trust” to actually verifying the system works? Set up Milestones and Measures.

Milestones - the kind you'd configure through an Entitlement Process in Salesforce - show you where the blockers are, where a Case or Opportunity is missing its timeline expectations, and gives you a place to build accountability into the status itself. For measure, think in terms of “how many Cases get re-classified?” or “are X SLAs being met?” The key takeaway here is to start with questions, not dashboards.

Milestones and Measures also keep people from gaming the system because any change comes with pushback, a detail worth flagging for any CoE or adoption conversation. If you are curious of what I am referring to, google the phenomenon called the Cobra Effect which describes when an attempted solution to a problem makes that problem worse. The history of the Cobra Effect is also a great read.

One implementation note here: when a client says “I want an alarm when X happens,” what they usually want is a filter. A way to see the data early enough with enough clarity to take the right action before the alarm would ever fire.

Over time, the system gets better with daily and weekly iteration: the client adds values, tweaks existing ones, brings in data from source systems for better threshold insight, and works on the source-system data management that usually needs attention anyway: IoT data on assets, SAP source alignment, metadata management. All standard implementation work. AI doesn't replace it; it depends on it.

The Use Case

I could have used Insurance Claims Triaging, Loan or Credit Approvals, or Support Ticket Resolution instead. The first two are high-stakes and heavily regulated; the support ticket use case is one I've seen too many times, and it's simple enough to be less useful as a teaching example. Case to Quote/Invoice sits in the middle - enough complexity to be honest about, simple enough to actually walk through in a few articles.

(Contract and Vendor RFP Response Drafting is another one I'll cover later. It's a strong ROI use case for content generation rather than pricing, and it's sustainable across a lot of divisions. In short: The workflow is for a proposal team response to a client RFPs. The inputs are a 40-page RFP document and a scattered email thread of internal answers. The recurring task: turn that into a structured list of answerable requirements.)

The design question underneath all of these use cases is the same: “Why did the system decide this?”

That question is why you'll need metrics, not vibes or assumptions. Regulatory and audit requirements like fair lending laws, for example apply directly to the high-stakes use cases, and every other use case still needs its own version of “how do we know we're succeeding, and what's the gap if we're not?” Some of this classification can be handled by fixed rules; the higher-stakes cases need more. More values, policy rules, and often complex regional policies overlay sitting on top of the base rules.

Past that layer is where a generative system can produce a quote draft, an explanation, or a piece of correspondence and where things can go off the rails if you haven't done the groundwork. I'm not saying that to be dramatic. I'm saying: put a number on it, know how you'll hit that number, and set expectations by doing the prep work first; Case Types, source data and access, historical data, metadata, reporting, page layouts. Do your homework before you promise anything. It's extra work you might not get separately billed for, but it buys you Clarity.

Clarity

A quick note on Clarity. Clarity is what you want. Clarity promotes Calm. Calm provides Focus. Focus drives Confidence. If you're the lead on one of these projects, people are measuring your confidence every day, whether they say so or not. Doing the groundwork above is how you earn it honestly instead of faking it. These are projects that can get under you real quickly.

The Vocabulary You Actually Need for This Use Case

For this use case, Case to Quote/Invoice with a threshold that branches to a customer YES/NO or a human checkpoint, here's the handful of terms that actually do work in the design:

Terms Sheet:

Deterministic or Structured: deterministic means the same input always produces the same output, and you can point to exactly which rule fired. This is why it is coupled with Structured data.

Probabilistic or Unstructured: Probabilistic means the output reflects likelihood, and the same input can produce different outputs across runs. This is why it works with unstructured data sets like email and chat or voice. As mentioned, there may also be multiple asks in one email pertaining to an issue with an asset and another invoice with an invoice.

Threshold: the cutoff value that determines which path a case takes: straight-through to the customer, or to a human. It can be static, or it can move as you get more data.

Confidence vs. Correctness: these get conflated constantly, so it's worth being precise.

Confidence is a probabilistic estimate of how certain the system is. Correctness is 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.”

Where probability actually creeps in is at the edges; rule ambiguity (the policy language itself is vague, so reviewers disagree) or measurement noise (your human labelers make mistakes too). Neither of those makes correctness itself fuzzy; it means your ‘ground truth’ needs its own adjudication process.

False Positive / False Negative: a false positive here is an auto-approved quote that shouldn't have gone through. A false negative is a good quote that got routed to a human unnecessarily. Your threshold is a tradeoff between these two costs, not a “right answer” you calculate once and forget.

Human-in-the-loop (HITL): the workflow pattern where a human reviews, approves, or overrides the system's output before it's final. This is your YES/NO click, and it's the deterministic check that re-enters the process on the other side of the generative layer.

Escalation path: the defined route a case takes when it doesn't meet the automated criteria. This is your human checkpoint, and it needs to be a real, designed path and not a fallback nobody built.

That's the working vocabulary. Everything else; Model vs. Agent, Temperature, Grounding, Hallucination, and the rest is useful to know, but it belongs to the people building the generative layer, not to the person designing where it fits in the implementation. I’ll cover these later in future articles once we establish the grounded truth.

Coming in Part 2 >>>

Applying the Case Types, preparation, multiple source systems, project experiences, processes and more.