Salesforce research published in November 2025 found that 84% of data and analytics leaders believed their data strategies needed a major overhaul before their AI ambitions could succeed. The same study found that leaders considered 26% of their organizational data untrustworthy, while 89% of respondents with AI already in production had experienced inaccurate or misleading AI outputs. Those findings don’t mean every organization has the same problem. They show why AI puts much more pressure on the data underneath business systems.
Salesforce teams have dealt with duplicate Contacts, incomplete Accounts, old picklists, and inconsistent custom fields for years. People often learn how to work around those problems. A service representative may know which status field nobody updates. A sales manager may know that billing information in the CRM should be checked against the ERP. An AI agent doesn’t automatically inherit those unwritten rules.
That changes what AI Readiness for Salesforce needs to cover. The question goes beyond whether the CRM is clean. Teams need to know whether the exact information required by an AI use case can be found, interpreted correctly, connected to the right record, accessed under the proper permissions, and trusted enough for the action being considered.
VALiNTRY360 approaches this problem by looking at the Salesforce environment through the use case the AI will actually support. That keeps preparation focused on the records and sources that matter instead of turning AI readiness into an open-ended cleanup project.
What AI readiness for Salesforce actually means
AI readiness for Salesforce means that the information required by a defined AI use case is reliable enough for the system to retrieve and interpret it within the boundaries of that task. Salesforce describes AI data readiness as a fit-for-purpose question and distinguishes it from ordinary data quality. Its current guidance examines whether required structured information and unstructured content are available, whether critical data can be trusted, and whether the agent has suitable access.
| Readiness level | Main question |
| CRM usable | Can employees complete the business process with the records available? |
| Data reliable | Can important business information be trusted for its intended purpose? |
| AI ready | Can AI retrieve and correctly interpret the required information? |
| Agent ready | Can an agent use that information within defined action and access limits? |
A formal review can help teams identify those gaps before an AI build begins. VALiNTRY360’s AI readiness services examine the data foundation and related Salesforce conditions that can affect AI projects. Salesforce’s own AI Data Readiness Assessment Fundamentals provides a useful technical basis for this distinction.
Why clean Salesforce data can still fail an AI use case
Traditional Salesforce data quality checks usually ask whether records are complete, duplicates exist, fields follow expected formats, and integrations are operating. Those checks still matter. AI introduces another question: can the system correctly understand and apply that information to the decision in front of it?
| Normal CRM check | AI readiness question |
| Is the field populated? | Is its value reliable enough for this decision? |
| Is the record valid? | Is it associated with the right customer or transaction? |
| Is the integration active? | Is the retrieved value current enough? |
| Can the user access the record? | Should this agent have access to it? |
| Is the document stored? | Is the approved version retrievable? |
| Is the field documented? | Is its business meaning clear enough for AI interpretation? |
Consider a field called Preferred_Product__c. It may be filled on almost every Account. That looks healthy in a completeness report. The field becomes poor AI input if sales stopped maintaining it 18 months ago and nobody removed it from the process. A person familiar with the org may ignore it. An agent that receives the field as context has no reason to make the same assumption.
Salesforce’s structured-data guidance makes the same broader point. Reliable structured records supply the context that allows an agent to interpret information such as customer messages or documents correctly. Incorrect relationships and inconsistent metadata can leave the agent reasoning over fragmented information. Teams planning broader AI work can connect this assessment to their Salesforce AI solutions instead of treating data preparation as an isolated cleanup task.
Define the AI use case before you audit the data
The first useful readiness question is simple: what exactly is the AI supposed to decide, answer, or do? That answer determines which data deserves attention first.
Suppose a service agent must decide whether a customer qualifies for a product return. The team can map the requirement before reviewing thousands of fields:
Business action
Determine whether the current request meets the return policy and either continue the process or route the case for review.
Required Salesforce context
· Customer identity
· Relevant Case
· Product or SKU
· Purchase date
· Order
· Entitlement where applicable
· Current case status
Required content
· Approved return policy
· Product-specific exceptions
· Warranty rules where relevant
· Current service instructions
Required outside data
· Payment status if maintained outside Salesforce
· Shipment state where the decision depends on delivery
· Other transaction information required by the policy
This map identifies the critical data elements. Those are the fields and records that directly affect the result. A Salesforce org might contain hundreds of fields that have no bearing on this particular action. Spending weeks repairing them doesn’t make the first AI use case safer.
VALiNTRY360’s Agentforce readiness assessment follows the same practical principle by tying readiness findings to the use cases an org plans to run. This approach keeps Salesforce AI readiness connected to an actual business action instead of an abstract score.
Which Salesforce data should you check first for AI readiness?
Salesforce’s current readiness model provides a useful way to prioritize the review. It looks at availability, accessibility, criticality, completeness, consistency, correctness, recency, uniqueness, and sensitivity.
| Data prerequisite | Question to answer |
| Availability | Does the information required by the use case exist? |
| Accessibility | Can the agent reach the permitted records and fields? |
| Criticality | Which data elements actually determine the result? |
| Completeness | Is enough information present to support the action? |
| Consistency | Does the same value mean the same thing across sources? |
| Correctness | Can the critical value be verified? |
| Recency | Is it current enough for this business decision? |
| Uniqueness | Could overlapping identities create conflicting context? |
| Sensitivity | Should the agent be allowed to retrieve this information? |
These checks shouldn’t receive equal weight in every project. A shipping-status agent may care deeply about recency because yesterday’s shipment state is already wrong. An employee-policy assistant may care more about document version and applicability. The use case determines which weakness creates real risk.
This is why Salesforce data readiness can’t be reduced to a generic org-wide quality percentage. A dataset can score well overall while failing badly on the 5 fields an agent needs to make a particular decision.
How to assess structured Salesforce data for AI
Structured Salesforce data provides much of the context that tells AI who the customer is and which transaction applies. Salesforce specifically warns about incomplete or abandoned fields, disconnected records, conflicting values, duplicate records, and metadata problems because they can cause an agent to work from misleading context.
| Check | What to examine | Potential AI problem |
| Critical field completeness | Nulls on required fields | Agent lacks required context |
| Placeholder values | “Unknown,” generic defaults, zeros | Populated field creates false certainty |
| Picklists | Old or overlapping values | Meaning becomes inconsistent |
| Record age | Last meaningful update | Agent uses outdated business facts |
| Ownership | Inactive or unclear owners | Nobody corrects bad information |
| Relationships | Contact, Account, Case, Order links | Agent applies correct information to the wrong situation |
| Duplicate patterns | Contacts, Accounts, transactions | Conflicting customer context |
| Custom fields | Real usage and definition | Old technical debt enters AI context |
The fields employees already know not to trust
Some of the most dangerous fields look healthy in a report. They contain values, meet validation rules, and appear on the page layout. Experienced users still know they shouldn’t rely on them. A previous workflow may have stopped updating the field. A new system may have replaced it. Several teams may interpret the same picklist differently.
Data profiling helps expose those cases. Teams preparing for AI should examine value distribution, default-value frequency, last meaningful updates, relationship coverage, and field usage rather than stopping at null counts. Data remediation that requires mapping or consolidation can also connect to VALiNTRY360’s Salesforce data migration services when the problem extends beyond ordinary field cleanup.
How to handle duplicates, broken relationships, and identity resolution
Duplicate cleanup receives plenty of attention in Salesforce projects. AI adds a reason to look beyond the duplicate count. The system also needs to know whether records that appear related really represent the same person, company, order, or business relationship.
Do 2 records represent the same real-world entity?
If no, preserve the separation. If yes, determine why both records exist.
Are they accidental duplicates inside Salesforce?
Review whether they should be merged under existing data-management rules.
Do they represent the same entity across different systems?
Identity resolution may be more appropriate than physically merging the source records.
Is the separation required by a legal entity, security boundary, or business model?
Keep the records distinct and make sure the AI context respects that distinction.
Broken relationships deserve the same attention. An accurate Case tied to the wrong Contact still creates bad context. An Order without the right customer link can stop the agent from connecting a valid policy with the relevant transaction. Salesforce’s structured-data guidance specifically warns that disconnected customer and transaction records can leave an agent with an incomplete view.
When the use case spans several source systems, Salesforce Data 360 services may become relevant because identity resolution can connect source records into a unified profile while preserving the underlying source data where needed.
Why metadata and field meaning matter to Salesforce AI
Metadata is one of the easiest prerequisites to overlook because it doesn’t look like missing customer data. Yet Salesforce explicitly identifies metadata gaps as an AI reliability problem. Its current guidance says metadata should help explain field definitions, ownership, sensitivity, acceptable values, and usage so agents can interpret information within the correct context.
Take a field called Customer_Status__c. A 100% completion rate tells you that every record contains something. It doesn’t tell you what the value means. AI readiness requires more:
| Metadata item | What needs to be known |
| Definition | Exact business meaning |
| Owner | Team responsible for the definition |
| Source | Where the value originates |
| Accepted values | Which values are valid |
| Update rule | When and how the value changes |
| Sensitivity | Access restrictions |
| AI usage | Whether the agent may retrieve or act on the value |
| Status | Whether the field is active, replaced, or deprecated |
A common failure appears when 2 similar fields carry different meanings. Customer_Tier__c may describe commercial value while Support_Tier__c controls service entitlement. A person familiar with the org sees the difference immediately. An AI workflow needs the surrounding metadata and use-case design to prevent the wrong field from becoming decision context.
Salesforce’s guidance on reliable AI data readiness recommends documenting these meanings and governing which sources agents use. Teams with wider architecture questions can connect that work to VALiNTRY360’s Salesforce consulting services.
How to prepare Knowledge, PDFs, and other content for AI
AI readiness has to examine information outside normal CRM fields. Salesforce agents can depend on Knowledge articles, uploaded files, customer messages, case notes, contracts, transcripts, or other unstructured material. The presence of a document doesn’t prove that the document is safe to use.
Use a simple content lifecycle: Find it -> verify it -> associate it -> retrieve it -> retire it
| Content question | Why it matters |
| Who owns this content? | Someone needs authority to approve changes |
| Which version is current? | Old documents can generate old instructions |
| What does it apply to? | Product, geography, date, or customer context may matter |
| What record should it relate to? | Correct content still fails when attached to the wrong business context |
| Can the AI retrieve it? | Storage doesn’t guarantee retrieval |
| Should any facts become structured fields? | Repeated business decisions may need controlled values |
Consider a return-policy PDF. The document may be current and accurate, but the agent can still fail if an older version remains indexed. The same problem appears when policies differ by country and the document carries no metadata that tells the system where it applies.
Salesforce Agentforce Data Library can index selected Knowledge articles, uploaded files, or custom retrievers and use a search index and retriever for grounded answers. The technical pattern connects closely with VALiNTRY360’s agent design guidance on retrieval, tools, and guardrails.
Which source should Salesforce AI trust when systems disagree?
A modern Salesforce environment rarely owns every business fact. CRM may own customer identity. ERP may own invoice status. A commerce platform may have the latest order state. A product database may contain the current usage event.
That means “create one source of truth” is often too vague. AI readiness needs a source rule for each critical fact.
| Data element | Possible authoritative source | Readiness question |
| Customer identity | Salesforce CRM | Which system owns the customer profile? |
| Invoice status | ERP | Where is payment state considered final? |
| Shipment state | Fulfillment platform | Which value is current enough for service decisions? |
| Contract terms | Contract system | Which approved agreement controls? |
| Product activity | Product platform | Which system records current usage? |
The important part comes when systems disagree. If Salesforce says an account is active while the billing platform says service has been suspended, the agent needs a defined precedence rule. The architecture may use the billing system for that particular decision even though Salesforce remains the primary customer system.
The readiness record for each critical element should state its authoritative source, acceptable age, synchronization behavior, conflict rule, and fallback behavior. Organizations working across several applications can use Salesforce integration services to address source mapping and synchronization issues that surface during the audit.
How permissions and sensitive data affect AI readiness
Permissions shape the information an agent can use. An accurate field may still be inappropriate context if the agent shouldn’t see it. A required field can create the opposite problem when security settings prevent the agent from retrieving it.
| Access layer | Readiness question |
| Object | Does the agent need this object? |
| Record | Which records belong in the permitted context? |
| Field | Which attributes may the agent retrieve? |
| Integration | What can connected credentials expose? |
| Write | Which values may the agent change? |
| Approval | Which actions require human review? |
Read and write rights also need separate decisions. A service agent might need to read an invoice balance to answer a question without receiving permission to change financial data. An account assistant might inspect a discount tier but require a manager before writing a new commercial term.
Current Salesforce documentation adds an important detail. Pattern-based and field-based Einstein Trust Layer data masking for LLMs is disabled for agents because masking can remove context required for a useful response. Other Trust Layer protections remain, but teams shouldn’t rely on a blanket assumption that agent context is automatically masked. Salesforce explains this limitation in its Agentforce data masking documentation. This makes field-level security and careful data selection especially important. VALiNTRY360’s Agentforce testing guide covers the testing side once those controls are configured.
When Data 360 and Agentforce Data Library become part of readiness
Data 360 becomes relevant when the AI use case needs information spread across systems, identity resolution, connected customer context, or indexed content for retrieval. The architecture should follow the use case rather than starting with a product assumption.
A useful flow is: Source systems -> connection -> identity and context -> index or retriever -> agent -> permitted action
Agentforce Data Library is more specific. Salesforce currently requires Data 360 to be set up before a Data Library can be used, and Data Libraries consume Data 360 credits. A library can use Knowledge, uploaded files, or a custom retriever as its selected source. Salesforce creates a search index and retriever for the chosen source.
Current source rules deserve attention before teams build the library. Salesforce says one library can’t support several data sources simultaneously. Once a source is chosen, it can’t later be changed for that library. Multiple libraries can exist, but each feature uses one library at a time. Teams should therefore decide what information belongs together before indexing it. Salesforce documents these rules in its Data Library source guidance.
A short consumption check
Data scope can also affect cost. Salesforce currently lists Data 360 Flex Credits at $500 per 100,000 credits, while processing activities such as unstructured data work and queries can depend on usage. Contract terms can differ. Teams can verify the current figures on the Salesforce Data 360 pricing page. Processing a large volume of irrelevant material creates technical work and may create avoidable consumption, which is another reason to scope sources around the use case. VALiNTRY360’s Data 360 evolution guide provides additional platform context.
How to measure Salesforce data readiness before an AI pilot
Readiness needs evidence. Arbitrary percentages copied from another company’s checklist don’t tell you whether your use case can operate reliably.
Start by profiling the critical data identified earlier:
| Measure | What it tells you |
| Null rate on critical fields | Whether required context exists |
| Placeholder frequency | Whether populated fields carry useful values |
| Duplicate frequency | Potential identity conflicts |
| Record age | Potential freshness problems |
| Relationship coverage | Whether the agent can connect the customer and transaction |
| Source disagreement | Whether connected systems conflict |
| Content age | Whether knowledge may be outdated |
| Retrieval success | Whether required information appears when tested |
The acceptance criteria should reflect the consequence of being wrong. A missing marketing preference and a missing eligibility field don’t create the same operational risk. The team should define which critical data elements are mandatory, what age is acceptable, and when a missing fact requires human review.
Salesforce’s current readiness material supports this evidence-based approach. It uses profiling to expose unreliable fields and turn findings into architecture decisions instead of treating all fields equally. VALiNTRY360 uses its own weighted method in its readiness work, but those weights should be understood as a VALiNTRY360 assessment model rather than a universal Salesforce standard. Teams that need a wider CRM assessment can also use its Salesforce CRM consulting services to connect AI findings with the underlying org design.
How Salesforce AI readiness can drift after launch
Passing a readiness check today doesn’t freeze the Salesforce environment. Business systems continue changing after the AI pilot goes live.
A team might add a new status field. Service could revise its Knowledge articles. An ERP integration might move to a new endpoint. Permission sets may change. A business unit could start using a picklist differently. Any of those changes can alter the context available to an agent.
A practical post-launch review should therefore monitor several conditions:
· Critical field completion and value patterns
· Changes to field definitions
· New duplicate or relationship problems
· Failed or delayed integrations
· Knowledge review dates
· Retrieval failures
· Permission changes
· Source changes for critical facts
· Escalations caused by missing information
This is where Agentforce data readiness becomes an operating condition rather than a one-time project. NIST’s AI Risk Management Framework also treats AI risk management as a lifecycle activity that continues across use and evaluation, rather than ending at deployment. Readers who need the neutral risk framework can review the NIST AI Risk Management Framework.
Ongoing Salesforce administration matters here because a clean launch can deteriorate as business rules change. Salesforce managed services can support continued platform care where an internal team needs help maintaining those controls.
Salesforce AI readiness checklist: go, fix, or pause
A useful final readiness check should focus on evidence from the planned use case. Use the questions below before moving an AI agent into a serious pilot.
Use-case scope
· Is the AI decision or action clearly defined?
· Are the required objects and sources known?
· Have the critical data elements been identified?
· Is there a clear boundary for what the agent shouldn’t do?
Data reliability
· Are required values present?
· Are placeholder values identified?
· Are critical values current enough?
· Are important record relationships intact?
· Have duplicate identities been assessed rather than automatically merged?
Meaning and ownership
· Do important fields have clear definitions?
· Does each critical field have an owner?
· Is the authoritative source defined when several systems carry the same fact?
· Are source-conflict rules documented?
Content and retrieval
· Are approved document versions known?
· Has old content been retired from the AI source?
· Is each document associated with the correct context?
· Can testing retrieve the required content consistently?
Access and action
· Can the agent see only the records and fields needed for the use case?
· Are sensitive attributes controlled through the appropriate Salesforce security settings?
· Are write actions limited to approved fields or processes?
· Is human approval required for higher-risk actions?
Failure handling
· Does missing critical information cause a safe escalation?
· Can the team identify whether a bad response came from source data, retrieval, access, or model behavior?
· Is there an owner responsible for correcting the underlying data problem?
The decision then becomes straightforward.
Go
The critical information needed for controlled testing is available and sufficiently reliable under the agreed acceptance criteria.
Fix
The use case is well defined, but identified data or access problems need correction before the pilot can provide trustworthy evidence.
Pause
The team still can’t identify the required information, the correct source, or the permitted action boundary. Building the agent at that point moves uncertainty into testing rather than resolving it first.
VALiNTRY360 can use the findings from this type of review to connect data work with architecture and pilot planning. Its Agentforce readiness assessment provides a formal next step for organizations that want their Salesforce environment checked against a defined Agentforce use case.
Frequently asked questions
What does AI readiness for Salesforce mean?
AI readiness for Salesforce means the data required by an AI use case can be retrieved and interpreted reliably within the permissions and business rules that apply to the task. It should be assessed against the planned use case rather than the condition of every record in the org.
How is Salesforce AI readiness different from Salesforce data quality?
Salesforce data quality checks whether information is accurate enough for its normal business purpose. Salesforce AI readiness adds questions about context, field meaning, source authority, access, retrieval, and whether the information is reliable enough for the AI action being considered.
Does all Salesforce data need to be cleaned before using AI?
No. Start with the objects, fields, relationships, documents, and connected sources required by the first AI use case. Other data can be reviewed later unless it affects those records or changes the context the agent receives.
Which Salesforce data should be audited first for AI?
Audit the information directly tied to the agent’s decision. That often includes critical customer records, transactions, related objects, Knowledge content, and any external facts required by the process. The exact scope depends on the use case.
What are critical data elements in a Salesforce AI use case?
Critical data elements are the fields or records that directly affect whether the agent can reach the correct outcome. Missing or unreliable critical information should usually block the action or trigger a defined human-review path.
How do duplicate Salesforce records affect AI?
Duplicates can present conflicting identities or transaction histories to the agent. The correct response depends on why they exist. Accidental duplicates may need consolidation, while cross-system or legally separate records may need identity rules that preserve the original boundaries.
Why does metadata matter for Salesforce AI?
Metadata tells the system what a field means, where its value comes from, who owns it, which values are valid, and whether it contains sensitive information. A populated field can still be unsafe AI context when those definitions are missing.
How fresh does Salesforce data need to be for AI?
There is no universal freshness requirement. The acceptable age depends on the business decision. Inventory or payment status may need very recent information, while some historical profile attributes can remain valid for much longer.
What makes Salesforce Knowledge ready for AI?
Knowledge should have a clear owner and an approved current version. Old content should be retired from the retrieval source, and the article should contain enough context to determine when it applies. Retrieval should also be tested before production use.
How should PDFs and uploaded files be prepared for Agentforce?
Review ownership, version, applicability, permissions, and whether important facts need to be represented as controlled fields. The file also has to be indexed and retrievable through the chosen Agentforce data source rather than merely stored somewhere in Salesforce.
Does Agentforce Data Library require Data 360?
Yes. Salesforce currently states that Agentforce Data Library requires Data 360 to be set up and that Data Libraries consume Data 360 credits. The requirement applies specifically to Data Library and shouldn’t be generalized into one architecture for every Agentforce use case.
How should Salesforce AI handle conflicting data from different systems?
Define which source is authoritative for each critical fact. The rule can differ by data element. Billing information may come from ERP while customer identity comes from Salesforce. The AI design also needs a fallback when the authoritative source is unavailable.
How do Salesforce permissions affect AI agents?
Permissions determine which objects, records, and fields an agent can retrieve. Write access needs a separate review because information required for context doesn’t automatically need to be editable. Sensitive data should be controlled through appropriate Salesforce security settings.
How can Salesforce AI readiness be measured?
Measure the condition of critical data rather than using a generic score alone. Useful checks include completeness, placeholder frequency, relationship coverage, duplicate patterns, freshness, source disagreement, content age, and retrieval performance.
What data issues should stop an AI pilot from going live?
A pilot should pause when critical information can’t be identified, the authoritative source is unclear, important relationships are unreliable, required content can’t be retrieved consistently, or the agent lacks a safe access and escalation model.
