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.