Your Team Knows Which Salesforce Fields to Ignore. AI Doesn’t.

Ask a team whether its Salesforce data is ready for AI and the answer is nearly always about cleanliness: duplicates, blank fields, inconsistent formats. Those matter. But the question that actually decides data readiness for AI is a different one, and it is rarely asked until an assistant gives a confident answer that turns out to be wrong.

The question is this: does every field the assistant reads still mean something to somebody?

Most orgs cannot answer it, and most teams have never needed to, because people have always known which fields to ignore.

Your team reads selectively. An assistant reads literally.

Anyone who has worked in a Salesforce org for a year carries a private map of it. Lead Source stopped meaning anything after the marketing reorganization. Probability is set automatically by stage, so nobody looks at it. The real status of a deal is in Next Steps, not in the stage. The Industry field on old accounts was filled in by an intern in 2022 and has not been touched since.

None of that is written down anywhere. It does not need to be, as long as the only readers are people who learned it from each other. They skip the fields that lie and read the ones that do not, and they do it without thinking.

An assistant connected to the same org gets the schema without the folklore. It reads every field with the same confidence. It will tell you that a customer is in retail because the Industry field says so, report a 70% probability because the field says 70, and summarize a deal from its stage while the note that says the buyer left the company sits two fields further down.

Gartner put the underlying problem plainly: in traditional data management, “uses of data are not well-documented,” and organizations “lack the required practice and metadata to assess the readiness of data for AI.” In a Salesforce org, the missing metadata is not exotic. It is the answer to which fields mean what, and to whom.

Four kinds of field that mislead an assistant and never fool a person

In the orgs we work on, the fields that cause trouble fall into four recognizable kinds. None of them is a data quality problem in the usual sense, which is exactly why they survive data quality work.

The abandoned field. Still populated, because a default value, a validation rule or an old automation keeps filling it, and read by nobody. It scores perfectly on completeness. It means nothing. People ignore it so reliably that nobody remembers it is there, until an assistant quotes it.

The field with two meanings. The same label, read differently by two teams. Sales marks a lead qualified when there is a conversation; marketing means it met a scoring threshold. Both are right inside their own reports, and the disagreement only surfaces when somebody compares totals. An assistant does not compare. It picks one meaning silently, and you do not find out which.

The field that was true once. Captured at creation and never maintained: employee count, industry, region, the customer’s primary product. Accurate on the day the record was made, and drifting ever since. People treat these as rough context. An assistant treats them as current fact.

The text field carrying the real answer. Next Steps, Description, a notes field nobody designed. The structured fields say one thing; the free text says what actually happened. A person reads the note first. An assistant may weight the structured field, because it looks more authoritative, and give you the official version of a story everybody on the team knows is out of date.

Why a data quality program will not find them

Data quality programs measure what can be measured: completeness, duplicates, formats, valid values. Every one of the four fields above can pass all of it. An abandoned picklist with a default is 100% complete. A field with two meanings has perfectly valid values. A stale employee count is correctly formatted. The problem is not quality. It is meaning, and meaning has no validation rule.

The research points the same way. In Salesforce’s State of Data and Analytics study, nearly half (49%) of data and analytics leaders said their companies occasionally or even frequently draw incorrect conclusions from data with poor business context. The same leaders estimated that over a quarter (26%) of their organizational data is untrustworthy. Poor business context is precisely the four fields above: values that are present, valid and wrong to read at face value. That is the gap a cleanup project leaves open, and it is the part of data readiness for AI that an assistant exposes first.

And the fix is less technical than it sounds. In a Gartner survey of 223 data and analytics leaders in March 2026, cultural resistance outweighed funding as the primary reason governance initiatives fail, 60% against 40%. Gartner’s conclusion was that AI-ready data also requires “AI-ready stakeholders.” In our experience that is the right way to put it, and it leads directly to the question worth asking.

The question to ask instead: who is this field for?

Every field in a Salesforce org was created for a reader. A report somebody needed, an approval that depended on it, a manager who wanted to see it on a page layout. As long as that reader exists, the field stays honest, because somebody notices when it is wrong.

When the reader goes away, the field does not. The report is retired, the approval is redesigned, the manager moves on, and the field keeps being filled, by habit or by automation, with nobody left to notice whether it is right. That is how all four kinds of misleading field are made. They are orphans.

So the useful version of the data readiness question is not “is our data clean?” It is a question asked field by field: who reads this, and would they notice if it were wrong? A field with an answer is safe to give an assistant. A field without one is not, however complete it looks.

Why it matters more once an assistant can act

While an assistant only answers questions, a misleading field produces a wrong sentence, and a person reading it has a chance to catch it. Once an assistant can update records, draft emails or route work, the same field produces a wrong action, and the person who would have caught it is no longer in the loop. An orphaned field that was a nuisance in a summary becomes a liability in a workflow. That is the practical reason data readiness for AI has to be settled before write access is on the table, not after.

This is also why the question cannot be answered by a tool. Profiling software can tell you a field is 98% populated. Only a person can tell you that nobody has looked at it since the last reorganization.

How to run it on the part of the org that matters

The mistake is to treat this as an org-wide data project. It is not, and it should not be, because org-wide projects do not finish. Scope it to what an assistant will actually read.

Start from the use case, not the schema. Pick the first thing you want an assistant to do, and list the objects and fields it would need to read to do it. That is usually three or four objects and a few hundred fields, most of which nobody would miss.

Give each field one of three outcomes. Keep: it has an owner who reads it and would notice if it were wrong. Define: people use it, but they mean different things, so it needs one written sentence of meaning before an assistant reads it. Hide: nobody owns it, so the assistant should not see it. Hiding is cheap and reversible. Deleting fields is a separate and much riskier project, and it is not what this is.

Settle the disputed fields rather than averaging them. When a field turns out to carry two meanings, there are only two honest options: agree on one and write it down, or split it into two fields that each mean one thing. The tempting third option, a definition vague enough that both teams can sign it, is worse than nothing, because it looks settled and is not. It is also the step that most often needs somebody senior in the room, which is the cultural point Gartner was making.

Name owners as roles, not people. “Sales operations” survives a resignation. “Maria” does not, and the whole point is to stop fields becoming orphans the next time somebody leaves.

Write the Define sentences where the work happens. Field-level help text, not a wiki. The person filling in the field sees it, and so does anyone, or anything, reading the field later.

Expose only what you kept. This is where the exercise pays for itself. Salesforce’s hosted MCP servers let you define exactly which objects and fields a tool returns through named queries, which we covered in what changed when Salesforce MCP made the connection easy. Scope is also the second of the decisions we work through before an assistant gets any access at all, in the guardrails we put in place before AI can write to Salesforce. And Salesforce is moving toward giving agents their own, narrower permissions rather than borrowing a person’s, which turns the field list into configuration rather than a document.

Re-run it when the org changes. A reorganization, a retired report, a new team: each one creates orphans. The review is much shorter the second time, because you are only checking the fields whose readers changed.

The half the platform cannot do for you

When we looked at what the Winter ’27 release updates mean for AI readiness, the conclusion was that the platform is now enforcing parts of the machinery: named identities, deliberate visibility, automation you can test. That is real progress, and none of it touches what a field means. A release can force you to say who an integration user is. No release can tell you whether your Industry field is still true.

That is the half of readiness that stays with the people who run the org. It has no deadline attached, which is exactly why it keeps losing to work that does, and it is also the half that decides whether an assistant’s answers can be checked by the people who receive them.

Our view

Data readiness for AI is usually framed as a cleanup project, and cleanup projects are easy to postpone because they never feel finished. We think it is better framed as an ownership question, and ownership questions can be answered in a few days for the part of the org an assistant will actually read.

An org where every field the assistant reads has an owner will still produce wrong answers sometimes. The difference is that somebody will notice, quickly, because the field belongs to them. That is the property that matters, and it is the one most orgs do not have yet. It is also the foundation the rest of the argument rests on, which is why we keep saying that the foundation, not the model, decides whether AI works.

Sources

All figures were read at the primary source on October 7, 2026, and are quoted with the source’s own attribution.

• Salesforce, State of Data and Analytics: “Study: 84% of Technical Leaders Need Data Overhaul for AI Strategies to Succeed” (November 4, 2025). Two double-anonymous surveys, June 27 to August 13, 2025: 3,800 analytics and IT decision makers and 3,852 line-of-business leaders across 18 countries. Source of the 49% (incorrect conclusions from data with poor business context) and 26% (organizational data estimated untrustworthy) figures.
• Gartner, Lack of AI-Ready Data Puts AI Projects at Risk (February 26, 2025). Q&A with Roxane Edjlali, Senior Director Analyst. Source of the quoted passage on undocumented uses of data and missing metadata.
• Gartner, Gartner Predicts 60% of Organizations That Ignore Data Governance Culture Challenges Will Fail to Govern AI Successfully by 2027 (September 21, 2026). Survey of 223 data and analytics leaders, March 2026. Source of the 60% against 40% finding and the “AI-ready stakeholders” quotation.