ChatGPT
Claude
Google AI
Copilot
An enterprise AI strategy that uses Salesforce is a short document. It names two use cases, a data owner, a permission review, and a kill criterion. A deck with twelve agents is a catalogue. Catalogues do not ship, and they do not tell you what to stop.
The failure shows up six months after the town hall. Twelve agents were named on a slide. Two of them are running. Both run as a system administrator, because the pilot returned nothing until the user was widened, and nobody put the wide grant back. People rewrite most of the drafts. The exception queue, such as it is, is larger than the work the agent finishes. The use cases stay on because they were announced. There is no sentence that says what would turn them off, and no date on which anyone has to read the counts. The catalogue came back as a live system.
Salesforce tells you to ground your data for use with Agentforce. That line sits on the Data 360 help page. Data Cloud was renamed Data 360 on 14 October 2025. Grounding means a person has said which records the model may read. The page on how agents work is the matching constraint: responses come from trusted business data, including CRM data and Data 360, and they are supposed to stay inside your rules. A strategy that skips the list of records has skipped the work. The town hall skipped it. The administrator login is what filled the hole.
Two use cases, not a portfolio
Pick two jobs people already do. A case summary and a follow-up draft is a sound pair. Qualification and meeting booking is another. They should sit on objects you already run, with a volume you can count in a month. The jobs themselves, and the person each one needs, are set out as finished work rather than as a theme. If you cannot describe the output a colleague can see, you do not have a use case. You have a heading.
Two is the number because each use case needs a source list, an exception path, and a person who will look at failures. Twelve agents on a slide have none of those. You can add a third after the first two have a measured result and a named owner. Until then the slide is a backlog with a strategy cover on it. A backlog is a fine thing to keep. Calling it a strategy is how it gets funded as if the decisions were already made.
Write each use case as a sentence: who does this today, what they read, what they write, and what they refuse. If the sentence has a hole, it is not a use case yet. Do not fill the hole with the name of a model. A hole that says "and then it handles the complex ones" is the hole that ate the town hall. Complex is not a job. A refusal is a job. Write the refusal in the same sentence as the work, or the refusal will be designed later, which means after something has already been sent.
Choose the pair by what you can count and what you can stop. A summary you can compare with the case, and a draft a person still sends, can be killed if the rewrite rate stays high. An agent that runs the whole service desk cannot be killed cleanly, because nobody can say which part failed. Prefer the pair you can turn off without a programme reset. Ambition can wait for the third use case. It does not earn a place in the first two by being larger.
Volume is the other filter. A job that happens twice a month will not give you a rewrite rate you can stand behind, and the review date will arrive with an anecdote instead of a count. Pick work you already do often enough that a month produces a sample a person can read in an afternoon. If the only candidates are rare, the strategy is to wait. A thin use case kept alive so the document looks occupied will miss its criterion for lack of evidence, and someone will call the miss a reason to add ten more.
A data owner
Name one data owner. That person decides which objects and fields are in bounds, including anything brought in through Data 360. They also decide what is off limits: payment cards, health information, and anything under a legal hold. The owner is a job with a name, not a steering committee that aligns. A committee can advise. It cannot be paged when a field that should have been excluded shows up in a draft. A name can.
The source list is an artefact the owner signs. For each use case: the object, the fields, the Data 360 attributes if any, and the explicit exclusions. A field that is not on the list is out, including a field that would make the demo more impressive. The owner may add it later, in writing, after the use case has a result. They do not add it in the workshop to save the afternoon.
Data 360 does not appoint this person. Grounding is the instruction Salesforce gives you. The list of what "trusted" means in your org is the owner's list. If two systems disagree about a field on that list, the owner does not invent a tie-break in the prompt. Which system wins for that attribute is the programme decision in integration at programme level. The use case inherits the winner. A strategy that picks a different winner inside a prompt has created a third copy, and the draft will quote it.
Off limits means the job cannot see the field, not that the prompt says to be careful with it. Payment cards, health information, and legal holds are removed from the user the agent runs as. A prompt instruction is a hope. A field the user cannot read is a control. The owner and the person who administers permissions both have to be able to show that absence. "We told it not to mention card numbers" is the sentence that appears after a card number has already been mentioned.
The permission review
Review permissions before the pilot. The user the agent runs as should see only what that use case needs. A permission set checked against the source list is the review. If the demo works only with a wide grant, the use case is not ready. Narrow the job or fix the data. Do not widen the user to save the workshop. The town hall's two surviving agents are what a widened user looks like six months later. The grant felt temporary. Temporary grants that make a demo pass are the ones that stay.
The data owner signs the source list. The person who administers permissions signs the set. Those are two signatures. One slide that says "security reviewed" is not a substitute. The signatures are dated, and they are checked again when a field is added. How that user is built, and why a Sales Cloud profile does not cover a marketing user or a Data 360 grant, is the practical half of this, in permissions across clouds. The strategy names the review. That page is how the review is actually done. Skipping it is how the administrator login becomes the design.
Test as the user who will run, on records that are missing the fields the happy path assumes. If the test passes only as a system administrator, you tested the wrong user. Write down what the real user can open. Anything on that list that the use case does not need comes off before the pilot, not after the first incident. An empty answer on a correctly narrow user is a successful test of the control. Opening the user until the answer appears is the breach.
The kill criterion
Write the condition that turns the use case off. Use a threshold you are willing to enforce. A workable shape: if a person rewrites most drafts after a month of real cases, stop and redesign, or stop entirely. Another: if the exception queue is larger than the work the agent finishes, the boundary is wrong. Another: if a sampled output contains a fact that is not on the source list, stop the same day. That last one is not a monthly conversation. A fact from outside the list is the control failing in public.
Put a date on the review. The data owner and the person who runs the queue both attend. Bring the counts: finished without rewrite, rewritten, escalated, and any output that quoted a field that was out of bounds. Keeping a use case alive because it was announced is how the catalogue comes back under a new title. The date is what makes the criterion real. A criterion with no date is a sentence in a strategy document nobody opens.
Agree the threshold while the use case is still small enough to stop. "Most drafts" means a number you pick in advance, such as more than half of a week's sample rewritten in substance, not in tone. Tone edits are not a kill. A rep who changes "Hello" to "Hi" has not rejected the job. A rep who deletes a discount, a date, or a claim about the account has. Count substance. If you count every keystroke, you will kill a job that is working, or you will define the threshold so loosely that it never fires. Write the difference down.
A strategy that cannot fire its kill criterion is a launch plan. Launch plans are fine. Call them that, and keep them separate from the two use cases you are actually willing to stop. The town hall was a launch plan. It had no off switch, so the two agents that happened to run became the strategy by survival. Survival is not a result.
What you bring back, and when
After the first month, three outcomes are honest. The use case met the threshold, so you keep it and you may design a third. The use case missed, so you redesign the source list and the refusal, once, and you set a second date. The use case missed in a way the redesign cannot reach, a missing record, a user who must see too much, a queue nobody will staff, so you stop. Stopping is a result. It is the point of having written the criterion before the announcement.
Do not replace a stopped use case with a renamed one in the same month. The catalogue returns that way: the draft agent becomes the "assist agent" with the same source list and the same rewrite rate. A new use case needs its own sentence, its own list, and its own date. The two that are still running are the strategy. Everything else is a backlog, and it can stay a backlog until those two have earned a third.
