Home / architect / ai-ready-data-architecture

ai-ready-data-architecture

Use when designing or auditing a Salesforce data architecture to support AI features — Einstein, Agentforce, Data Cloud, or custom ML models.

• v1.0.1
• Salesforce Spring '25+
• Updated 2026-10-03
• Scalability
• Reliability
• Operational Excellence

• ai
• data-cloud
• agentforce
• einstein
• machine-learning
• rag
• data-architecture
• data-quality
• vector-search
• feature-store

Open the skill folder on GitHub

Use this skill when designing or auditing a Salesforce data architecture to ensure it can reliably support AI features — including Einstein predictive scoring, Agentforce generative actions, Data Cloud-powered insights, and custom ML integrations. This is not a skill about enabling individual Einstein features; it is about making the underlying data model, field design, and data quality posture capable of feeding AI reliably. The difference between an org where Einstein Opportunity Scoring works and one where it produces junk predictions is almost always data architecture, not configuration.

Questions to Ask Before Configuring

Ask these before auditing a single field. Each traces to a gotcha in references/gotchas.md.

What a proper design adds over "just enabling the AI feature": the data the feature reads is complete, fresh enough, in supported field types, and visible to the user the AI runs as, and every licence the design assumes is confirmed.

Why AI-Readiness Is an Architecture Problem

AI features consume data. The quality of their output is directly bounded by the quality of their input. Salesforce AI features fail silently when:

• Key predictive fields have fill rates below 70% — Einstein models depersonalize predictions and revert to global averages (UNVERIFIED 2026-10-03: threshold and fallback behavior are not in any fetched guide).
• Text fields used for RAG retrieval are written in inconsistent formats, contain HTML markup, or are truncated — the retrieval model cannot chunk or embed them reliably.
• Data freshness is misaligned — a model trained on 90-day-old data scores against live pipeline records and produces stale recommendations.
• Fields are named inconsistently across objects — Data Cloud's harmonized data model cannot map them without manual field mapping on every ingestion run.
• Knowledge articles are structured for human readability rather than machine chunking — large monolithic articles with embedded tables and images do not retrieve well.

This skill addresses all five failure modes before they reach production.

Key Design Areas

1. Data Completeness for ML

Einstein predictive models require sufficient field fill rates to produce meaningful predictions. The minimum threshold for a field to influence a model is approximately 70% fill rate across training records. Fields below 40% fill rate are typically ignored by the model during feature selection, which means sparse data silently degrades prediction quality. UNVERIFIED (2026-10-03): the 70% and 40% figures are working heuristics, not documented model behavior. For Opportunity Scoring, the factors the model actually used can be read from SalesAIScoreModelFactor (Object Reference; needs the View Scoring Model Factors permission).

Assessment approach: For each object targeted by an Einstein feature, calculate fill rates for all candidate predictor fields. Use a SOQL aggregate query or CRM Analytics recipe. Flag fields below 70% for remediation before enabling scoring.

Null handling strategies:

• Structured defaults: Use Flows or validation rules to enforce minimum values on fields that are operationally required (e.g., Industry, AnnualRevenue on Account).
• Picklist curation: Replace open-ended text fields with picklists wherever values are enumerable. Picklist fields are categorical features that Einstein handles natively; free text requires NLP processing and adds noise.
• Graceful nulls vs meaningful blanks: Not all nulls are equal. A null LeadSource may mean "not captured" (data quality problem) or "organic" (valid state). Document which nulls are meaningful and which are gaps before applying defaults.

2. Structured vs Unstructured Data Placement

Not all data belongs in Salesforce standard objects. AI features have different optimal data sources:

3. Embedding-Ready Text Field Design

Text fields that will be embedded for vector search require deliberate design. Key rules:

• Minimum length for meaningful embedding: 50 characters. Fields shorter than this rarely produce discriminating embeddings (UNVERIFIED 2026-10-03, heuristic).
• Maximum practical length: 2,000 characters per chunk. Fields beyond 4,000 characters should be chunked before embedding (UNVERIFIED 2026-10-03, heuristic). Salesforce Long Text Area fields support up to 131,072 characters (Knowledge Guide (Classic), field types): these must be chunked before passing to an embedding model. On the native path, a Data Cloud search index configuration does the chunking and vectorizing (Generative AI guide).
• Format discipline: Strip HTML before storing in custom pipelines. Rich Text fields in Salesforce Knowledge store HTML markup by default. The native Answer Questions with Knowledge action supports Text Area (Rich) fields directly, so test before stripping there. The embedding model treats <p>, <strong>, and & as tokens, which pollutes the vector space.
• Language consistency: Mixed-language fields produce low-quality embeddings. If the org supports multiple languages, store language as a metadata field and route to language-specific embedding models.
• Semantic density: Fields that mix unrelated topics (e.g., a Description field that contains installation instructions, billing notes, and escalation history concatenated) produce generic embeddings. Split concerns into separate fields.

4. Knowledge Article Structure for RAG

Agentforce grounds responses through an Einstein Data Library: the Knowledge articles or uploaded files are indexed in Data Cloud, and a search index and retriever are created automatically (Generative AI guide, "Setting Up Data Libraries"). A library uses either Knowledge or file uploads, not both; you choose identifying fields and content fields, can restrict to public articles, and can filter by data category. Supported knowledge field types are Text, Text Area, Text Area (Long), and Text Area (Rich); encrypted text and URL fields are not used. The quality of retrieval is still determined by how articles are structured.

Chunking-friendly article structure:

• One topic per article. Do not combine related but distinct concepts in a single article.
• Lead with a declarative summary sentence (the first 150 characters are the most heavily weighted by most retrieval systems; UNVERIFIED 2026-10-03). Put the summary in the field you select as an identifying field, which the guide recommends be a concise outline of the article.
• Use H2/H3 headers to create natural chunk boundaries — retrieval systems often split on heading boundaries.
• Avoid tables for information that could be prose — tables do not chunk cleanly and lose context when split across chunks.
• Tag articles with structured metadata: product, version, audience, topic category. Metadata filters in retrieval reduce false positives.
• Maximum recommended article length before mandatory chunking: 1,500 words (UNVERIFIED 2026-10-03, heuristic).

5. Data Freshness Requirements

AI models decay. The sync cadence for AI-relevant data should be designed based on the velocity of the underlying business data:

6. Einstein Feature Store

UNVERIFIED (2026-10-03): "Einstein Feature Store" as a product name, and score fields such as EinsteinScoreReason1__c, appear in no fetched guide. What the guides document: Einstein predictions are stored as AIRecordInsight records with child AIInsightReason, AIInsightValue, AIInsightAction, and AIInsightFeedback records, naming the prediction field written (Object Reference); Opportunity Scoring model factors are in SalesAIScoreModelFactor; and custom feature extraction for AI Accelerator use cases is the AIFeatureExtractor part of AIUsecaseDefinition, which needs the CRM Plus licence and the product's CRM licence and reads batch features from CRM Analytics or Data Cloud (Metadata API Developer Guide). Key design decisions:

• Feature values are stored as custom fields on the scored object (e.g., EinsteinScoreReason1__c on Opportunity; UNVERIFIED as above). These fields are system-managed when Einstein scoring is enabled: do not repurpose them.
• Custom feature extractors defined via AIFeatureExtractor metadata allow Salesforce Industries Einstein to use domain-specific signals. Define extractors in a dedicated metadata set and version-control them.
• Avoid writing business logic that reads Einstein score fields at runtime — scores update asynchronously. Read them in reporting and recommendations, not in trigger-based decision gates.

7. Data Cloud as AI Data Layer

Data Cloud provides the harmonized data layer that connects disparate Salesforce and external data sources for AI consumption:

• Harmonized data model: Data Cloud maps ingested data to a canonical data model (individual, contact point, engagement, etc.; the Data Cloud guide calls it the Customer 360 Data Model, grouped into subject areas such as party, engagement, and loyalty). Each stream's category (Profile, Engagement, Other) cannot be edited after ingestion. Field mapping quality directly affects identity resolution and calculated insight accuracy. Invest in mapping before ingestion, not after.
• Calculated insights: Define calculated insights (ANSI SQL statements on Data Cloud data, per the Data Cloud guide; corrected 2026-10-03 from "SOQL-like expressions") to pre-compute features at the data layer rather than in real-time Apex. Pre-computed features are faster and more reliable than runtime calculation.
• Activation targets: Data Cloud can activate segments and calculated insights back to Salesforce CRM objects. Design the activation schema to match the target object's field structure — mismatched types cause silent activation failures.

8. AI-Ready Field Naming

Consistent field naming enables automated field mapping in Data Cloud and reduces manual mapping effort on every ingestion run:

• Use consistent prefixes for AI-relevant fields: AI_, ML_, Score_, Feature_.
• Avoid spaces and special characters in API names — underscores only.
• Document the semantic meaning of each field in the field description — Data Cloud's schema mapping UI uses descriptions as hints during automated mapping (UNVERIFIED 2026-10-03).
• Mirror field names across related objects where semantically equivalent (e.g., Industry__c on Lead and Account should map to the same canonical field in Data Cloud).

9. Data Quality Gates Before AI Activation

Before activating any Einstein or Agentforce feature, verify:

1. Completeness: Fill rate ≥ 70% on all planned predictor fields.
2. Consistency: Picklist values are clean (no duplicates from legacy migration, no "Other" comprising >20% of values).
3. Timeliness: Sync jobs are confirmed running and within target cadence.
4. Volume: Sufficient historical records exist for model training (Einstein requires at least 1,000 closed records for Opportunity Scoring; Case Classification requires 1,000 closed cases with populated target fields; UNVERIFIED 2026-10-03, Help-only figures).
5. No circular dependencies: AI scoring fields are not used as inputs to the same model that produces them.

Recommended Workflow

1. Identify AI features and their data dependencies. For each Einstein, Agentforce, or custom ML feature in scope, list the source objects, predictor fields, and target fields. Build a dependency map: Feature → Object → Fields → Fill Rate.
2. Run a data completeness audit. For each object and field in scope, calculate fill rates using SOQL aggregate queries or a CRM Analytics recipe. Flag fields below 70%. This is the single highest-value diagnostic step.
3. Classify data placement. For each data category (structured CRM records, high-volume events, knowledge content, binary files), apply the placement decision matrix to determine whether data belongs in Salesforce objects, Data Cloud, or an external store.
4. Remediate field design. Address identified gaps: enforce defaults via Flow or validation rules, curate picklist values, strip HTML from text fields destined for embedding, split monolithic text fields where semantic mixing is detected.
5. Design knowledge article structure. If Agentforce RAG grounding is in scope, audit existing Knowledge articles against the chunking-friendly structure guidelines. Create or update the Knowledge article template. Apply metadata tagging taxonomy.
6. Define and validate sync cadence. For each AI feature, specify the required data freshness SLA and confirm the sync mechanism (CDC, scheduled batch, MuleSoft, Data Cloud connector) can meet it; for Knowledge grounding the documented cadence is a daily reindex. Test with a representative data volume before go-live, then run python3 skills/architect/ai-ready-data-architecture/scripts/check_ai_ready_data_architecture.py <completed-assessment.md> to confirm required sections, the quality gate checklist, and declared AI features are present.
7. Run data quality gate checklist. Complete the pre-activation checklist (completeness, consistency, timeliness, volume, no circular dependencies). Document results. Obtain sign-off before enabling AI features in production.

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/well-architected.md
• templates/ai-ready-data-architecture-template.md
• scripts/check_ai_ready_data_architecture.py