Einstein Prediction
An Einstein Prediction is the scored output of a machine learning model that Salesforce trains on the org's own records to forecast a specific future outcome.
Definition
An Einstein Prediction is the scored output of a machine learning model that Salesforce trains on the org's own records to forecast a specific future outcome. Predictions appear as a number, a probability, or a category on a record field, and they update as the underlying record data changes. Built-in Einstein Predictions include Einstein Lead Scoring, Einstein Opportunity Scoring, Einstein Forecasting, and Einstein Case Classification. Custom Einstein Predictions are built through Einstein Prediction Builder by picking a target field, defining the training data filter, and letting Salesforce train and deploy a model.
The defining property is that Einstein Predictions live on Salesforce records and run on Salesforce data. Unlike LLM-generated text, a prediction is a deterministic score from a discriminative model; the same inputs produce the same output. Predictions surface in list views, reports, dashboards, flows, and Apex without requiring custom integration. The cost is bounded by the org's edition; built-in predictions are usually included, while custom Prediction Builder predictions count against a per-edition quota of how many models the org can have active.
Why Einstein Predictions are the steady cousin of generative AI
Built-in vs custom predictions
Built-in Einstein Predictions ship with Sales Cloud and Service Cloud editions: Lead Scoring (probability a lead converts), Opportunity Scoring (probability a deal closes won), Case Classification (predicted Type, Reason), Forecasting (predicted commit), Einstein Account Insights (account engagement signals). They train automatically on the org's data with no admin setup beyond enablement. Custom predictions are built in Einstein Prediction Builder; admins pick a target field on any object, define the training data filter, and Salesforce trains and deploys a model whose score writes to a new field on the object. Both surface the same way on records.
How a prediction is built in Prediction Builder
Prediction Builder walks admins through a wizard. Pick the object and target field. Filter the example records the model should learn from (closed opportunities, resolved cases). Pick the segment of records to predict on. Pick example fields the model can consider (the wizard suggests which fields correlate with the target). Salesforce trains the model and reports accuracy. If accuracy meets the threshold, the admin deploys the prediction and the score field appears on records. The whole process is no-code for an admin who understands their data. The work that matters is data preparation and field selection, not the wizard itself.
Where predictions surface and how they are used
Predictions surface on records as a field with a numeric or categorical value. List views can sort by prediction score. Reports can filter on prediction values. Flows can branch on predictions. Apex can read prediction fields. Lightning components can display them. Routing rules can use them. The flexibility comes from predictions being just another field on a record once they are written. The behavior is identical to any other custom field for purposes of downstream consumption, which is intentional and is why predictions integrate so cleanly into existing org behavior.
Refresh cadence, drift, and the retraining decision
Built-in predictions retrain on Salesforce's schedule (typically weekly or monthly depending on the feature). Custom predictions retrain on an admin-configurable schedule, defaulting to weekly. New records get scored as they are created or updated; existing records get rescored on the retrain cycle. Drift surfaces as accuracy degradation in the Prediction Insights page; a prediction that was 80 percent accurate at launch can drift to 70 percent over a quarter if the underlying business shifts. The fix is retraining with fresh data; if the business shift is fundamental, the fix is rebuilding the prediction from scratch.
Bias, explainability, and Top Predictors
Each Einstein Prediction surfaces a Top Predictors panel that shows which fields most influenced the score for a given record. The panel is the explainability layer. It helps users trust the score ("this opportunity is scored 85% likely to win because of the deal size, the engagement count, and the close date") and helps admins debug surprising scores. Bias detection in Prediction Builder flags when a prediction correlates with protected attributes (age, gender, race when applicable). The flag is the first step; removing biased features or rebalancing training data is the customer's responsibility.
Quotas, licensing, and the edition gating
Built-in predictions are included in Sales Cloud and Service Cloud Enterprise+ editions where applicable. Prediction Builder is licensed separately as part of Einstein for Sales or Einstein Analytics. Each edition has a quota for active custom predictions (typically 5 to 10 per org); above the quota, admins must retire old predictions before deploying new ones. The quota is a soft limit, not a hard one; expanding requires a sales conversation. Most teams stay well under the quota; orgs that hit it usually have several legacy predictions no one owns that can be retired without business impact.
When predictions are not the right tool
Predictions are excellent at scoring records against historical outcomes. They are bad at: generating text (use an LLM), making record updates (use a flow that reads the score), explaining business strategy (use Einstein Discovery's narrative output), forecasting at aggregate levels (use Einstein Forecasting specifically rather than building a custom prediction). Picking the right Einstein tool for the job avoids the trap of building a custom prediction to do something the platform already ships as a different feature.
How to build a useful Einstein Prediction in Prediction Builder
The successful path is: pick a clean target field on a high-volume object, audit the training data, build in Prediction Builder, validate accuracy on a holdout, deploy as a sandbox pilot, expand. The failed path is: build a prediction on a noisy target field, deploy directly to production, watch users distrust the scores.
- Pick the target field and confirm data volume
The target needs at least 400 examples per class for the model to learn. For binary outcomes (won vs lost) that means 400 of each at minimum, and 1,000+ of each is much better. Check before opening the wizard.
- Audit the target field labels
Confirm the target field is consistently labeled in the historical data. Inconsistent labels (some Closed Lost records that are actually Closed Won, some Cases marked Resolved when they should be Open) train a model that learns the inconsistency.
- Open Prediction Builder and run the wizard
Setup, Einstein, Prediction Builder, New Prediction. Pick the object and target field. Filter the example records (closed Opportunities, resolved Cases). Pick the segment to predict on (open Opportunities, in-progress Cases).
- Pick fields the model can consider
Prediction Builder suggests fields that correlate with the target. Accept the suggestions or pick manually. Exclude any field that is filled in after the outcome was decided (data leakage).
- Train and review the accuracy report
Salesforce trains the model and reports accuracy on a holdout set. Above 75 percent accuracy is usually deployable; below 65 percent rarely is. Read the Top Predictors to confirm the model is learning sensible signals.
- Deploy to a sandbox or pilot scope first
Deploy and let the prediction write to records for two to four weeks. Watch the prediction values against real outcomes. Real production behavior is the only honest evaluation.
- Schedule retraining and an accuracy review cadence
Weekly retraining is the default. Pull the Prediction Insights report monthly to catch drift. Trigger a rebuild when drift exceeds 10 percentage points or when the underlying business model shifts.
Built-in Einstein Prediction (Lead Scoring, etc.) or custom (Prediction Builder). Drives quota and configuration depth.
The field the model predicts. Must be picklist, boolean, or numeric. Drives data requirements.
The record filter that defines which historical records the model learns from. Quality drives accuracy.
The fields the model can consider when scoring. Exclude leakage-prone fields explicitly.
Weekly, monthly, or on-demand. Tune based on how fast the underlying business pattern shifts.
- Data leakage in eligible fields is the most common cause of predictions that look brilliant in evaluation and fail in production. Exclude any field filled in after the outcome was decided.
- Below 400 examples per class, the model has too little data to learn meaningfully. The wizard warns; admins still ignore the warning.
- Built-in predictions and custom predictions share the same surface but different licensing. Confirm SKU coverage before assuming Prediction Builder is available.
- Predictions drift as the underlying business shifts. A model trained in Q1 can degrade by Q3 without anyone noticing without scheduled accuracy reviews.
- Predictions are not magic. A prediction with 70 percent accuracy is wrong on 30 percent of records; downstream automation that treats predictions as certain creates incidents.
Trust & references
Cross-checked against the following references.
- Salesforce Einstein overviewSalesforce
- Prediction Builder referenceSalesforce
Straight from the source - Salesforce's reference material on Einstein Prediction.
- Einstein Prediction BuilderSalesforce Help
- Einstein Lead ScoringSalesforce Help
- Einstein Opportunity ScoringSalesforce Help
Hands-on resources to go deeper on Einstein Prediction.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does an Einstein Prediction score represent?
Q2. How do Einstein Predictions stay accurate over time?
Q3. What is the recommended minimum number of records needed to build an Einstein Prediction?
Discussion
Loading discussion…