Clean your Salesforce before you add an AI agent
An AI agent does not repair your org. It reads what is there, runs the automation that is there, and responds on your behalf.
Problems that staff learned to work around, such as duplicates, overlapping flows and loose access, can reach customers directly when no person reviews the answer. This guide uses Salesforce's Agentforce terms and covers seven steps to take before a first agent goes live: who it runs as, what it reads, which automation it can call, and how you test it. Limits quoted here were read on 28 October 2026 and can change.
The order of work
- Decide the first agent and its subagents.
- Settle who the agent runs as, and limit what a service agent can reach.
- Clean the objects and fields those subagents use.
- Check every flow and Apex class the agent could call, then fix names and descriptions.
- Keep rules that must never vary in flows and Apex.
- Test in a sandbox with your messiest records.
- Launch with a small scope, watch the traces, and widen it only when the results hold.
Decide who the agent runs as
Every agent runs as someone, and that decides what it can see.
| Kind of agent | Runs as | What follows |
|---|---|---|
| Employee agent | The logged-in user | That user's profile, field security and sharing apply, as they would to the person |
| Service agent | A dedicated agent user | The customer can reach whatever that user can reach, unless you limit it |
Salesforce's help page says you must proactively limit data access for a service agent, for example by a verified customer ID. It also says that for a service agent without credential verification, a flow runs as the agent user, and a flow set to run in system context without sharing ignores sharing rules.
So the first checks are about access, not data. Open the agent user and confirm it starts with minimal access, then add object access only where a flow, Apex class or prompt needs it. Salesforce calls this the principle of least privilege. Then open each action your agent uses, note the flow or Apex class behind it, and ask what that flow would return to a customer who is not signed in. This guide does not replace a security review of your org.
Clean what each subagent reads, not the whole org
Salesforce renamed agent topics to subagents in April 2026, so older pages still say topics. Each subagent has its own instructions and actions, and each reads a particular set of objects and fields. Salesforce's data-cleaning guidance says to clean only the data your agent needs and to spell out who is responsible for each set of data. That gives you three steps:
- Write down the subagents you plan to launch, in one line each.
- For each, list the objects and fields its actions read or write.
- Clean those first, and leave the rest of the org for later.
Define what clean means for each subagent before you start, and write it down as a "ready when" line. For example: no unmerged duplicates among active customer contacts, no blank values in the three fields the agent reads, and one named owner for each field.
Salesforce's readiness advice points the same way. Resolve duplicates, standardise formats such as "USA" and "U.S.", keep data current, and restrict access to the data the agent needs. Its Trailhead module adds a data dictionary, so that someone can say what each field means. The admin-side tools are the ones you already have: validation rules, Duplicate Management, SOQL queries to find stale values, and a flow that flags bad records for review.
Check every flow and Apex class before it becomes an action
Salesforce lets an agent call actions built on Apex, Flow, prompt templates or MuleSoft APIs. An org that has been in use for several years may hold automation that could be pointed at an agent. Not all of it should be. Run these four checks on each candidate:
- Does it respect sharing? Salesforce points Apex developers to
with sharingandWITH USER_MODE, and a flow set to system context without sharing ignores sharing rules. - Does it take only primitive inputs? Salesforce's considerations page says Flow and Apex actions take primitive types only, and that flows with picklist, currency or collection resources cannot be action references.
- Does it handle many records? Salesforce advises bulkifying Apex, so that it handles many records at once.
- Does it fit the action limits? On the page we read on 28 October 2026, Salesforce recommends at most 10 actions per subagent, sets a 60-second timeout for an action, and truncates outputs over 65,000 characters.
Then sort what you find into four groups, in our own words:
- Use: it passes all four checks and has one clear job.
- Fix: it is useful but needs tidying first.
- Defer: it depends on a Workflow Rule or process, or two automations write the same field.
- Exclude: it changes records in system context without sharing, until you have settled the access question above.
Salesforce's article on agent-ready automation suggests starting with one strong candidate, and so do we.
Make names and descriptions distinct
An agent decides which action to call by reading its name and description. Salesforce's developer guidance says to avoid naming actions similarly, because it can confuse the agent, and says clear, distinct subagents prevent overlap.
A naming problem becomes a routing problem. If your org has "Update Opportunity Stage", "Update Opp Stage v2" and "Stage Update (new)", the agent has to guess. Before you expose a flow, list your flows and Apex methods with similar names or blank descriptions, and rename them. Write one plain sentence on what each does and does not do. Salesforce stresses descriptions for actions, their inputs and their outputs.
Keep rules that must never vary in flows and Apex
Instructions are read by a model. Flows and Apex run deterministically, outside the model. Put rules that must never vary, such as limits, thresholds and approvals, in a flow or Apex, where you can test and audit them. Salesforce also says to retrieve rules held in knowledge articles instead of hard-coding them, so policy wording that changes often belongs in articles the agent retrieves. The instruction then says when to call the rule. Salesforce advises using a flow when a process needs more than three ordered steps.
Test in a sandbox, on your worst records
Salesforce provides Testing Center, which runs batch tests against subagents and actions. Its page says that testing agents can modify CRM data, and that testing consumes credits. Use a sandbox, not production.
Salesforce describes a loop of generated test cases, human validation, and a re-test after every change and after deployment. We add one step that Salesforce does not prescribe. Build some of the test cases from your messiest real records: the contact that exists twice, the account with a stale status, the customer whose name is spelled three ways. Those are the cases an agent is likely to meet.
After launch, watch the session traces. Salesforce offers Agentforce Observability, which includes session tracing, and Agent Platform Tracing, which records spans from Apex, Flows and prompt templates. Salesforce's tracing page says its reports run through Data 360 (formerly Data Cloud) and that turning on data collection raises credit consumption. We did not find a page saying every agent needs Data 360, so ask Salesforce to confirm that for your design before you plan on it.
Salesforce describes the Einstein Trust Layer as keeping your data out of model training, masking sensitive data, scoring toxicity and logging requests, and says its policies can vary between features. It does not turn a duplicate contact into the right contact, so treat it as one control alongside clean data and limited access.
Where we fit
We do not build agents. The Org Review shows what in your org an agent would depend on, and what to fix first.
The Org Review is our fixed-fee review of your Salesforce setup, from USD 3,500. It gives you a costed list of what needs fixing, what it costs to leave it and what the fix takes. You keep the findings whether or not you hire us for the work.
If you would like to talk it through, book a free twenty-minute call.
Sources
Statements about Salesforce in this guide were checked against these pages on 28 October 2026. Salesforce changes product names and limits often, so we quote a limit only with the date we read it.
Related guides
Start with the Org Review, not a contract
A fixed fee from USD 3,500, ending in a costed fix list you own outright. Book a free twenty-minute call about your first agent.