--- title: "Einstein Prediction Builder, honestly assessed" url: "https://trailassembly.com/salesforce-einstein-prediction-builder/" topic: "Agentforce and AI" published: "2026-09-19T04:06:13+00:00" updated: "2026-10-06T13:58:26+00:00" --- # Einstein Prediction Builder, honestly assessed **Short answer:** Einstein Prediction Builder is a declarative way to train a model on records you already have and write a score onto a field. You point it at an object, tell it which field holds the outcome, let it pick predictors, and it scores records on a schedule. It works when the outcome has been recorded consistently for a long time on a lot of records, and it fails quietly and impressively when it has not. ## What it needs from you Three things, and the first is the one that kills most attempts. **A recorded outcome.** A field that already says what happened: a checkbox for a yes/no prediction, a number field for a numeric one. Not an intention, not a stage. If your churn flag has been filled in properly since March and patchily before that, you have a few months of data, not two years. **Volume.** Salesforce enforces a minimum number of example records, and that minimum is far below what produces anything useful. Hundreds gets you past validation. Thousands, with a decent count in the minority outcome, gets you a model. Rare outcomes are the hard case: ninety-eight per cent “no” means a model that always says “no” is right ninety-eight per cent of the time and worth nothing. **Predictors that exist before the outcome.** More on this below, because it is where most models go wrong. ## What it produces A prediction field on the object. Binary predictions give a likelihood score from 0 to 100. Numeric ones give a predicted value. It behaves as an ordinary field for most purposes, appearing in reports, list views and flow conditions. You also get a scorecard reporting model quality, the top predictors with their relative influence, and performance by segment. Read the top predictors list before trusting anything else on that page. Scoring happens on a schedule, not instantly. A record created this morning is not scored this morning. Anything that needs a decision at the moment of creation is the wrong use case. ## Leakage, which is the real problem The model will happily use any field you leave available, including fields that only get populated after the outcome is known. Predicting whether an opportunity closes won, with Close Date and Loss Reason still in the field list, gives wonderful accuracy and no value. Same with predicting churn while leaving the cancellation date visible. The scorecard looks excellent. It is telling you the past, in a loop. The fix is manual. Go through the field list and exclude everything written at or after the moment the outcome is known, including fields filled in by the process that follows it. If the top predictor is something a human sets after the fact, start again. ## When it actually works - **[Lead conversion](https://trailassembly.com/lead-conversion-field-mapping/) likelihood**, where you have years of leads and a genuine conversion flag, and the predictors are firmographics and behaviour captured before conversion. - **Case escalation risk**, scored at case creation, predicting from product, account history, channel and priority. - **Late payment likelihood** on invoices, where the account’s own payment history is a strong and honest predictor. In each, the outcome is unambiguous, machine-recorded, and separated in time from everything used to predict it. ## An honest assessment Prediction Builder sits in an awkward spot: more capable than a formula, much less capable than a data scientist with the same data in a proper modelling environment. If you need control over features, sampling and thresholds, you want Einstein Discovery or something off-platform. The bigger risk is organisational. A score nobody acts on is decoration, and a score people distrust is ignored within a month. Agree first on what changes when the score is high. If the answer is “we look at it in pipeline review”, do not build it. Said plainly: a decent heuristic in a formula field, understood by the sales team, often beats a slightly more accurate model nobody can explain. Adoption is part of accuracy. ## Frequently asked **Does it need a separate licence?** It is a licensed Einstein capability, bundled with some editions and an add-on for others. Check what your org has before designing around it. **Can I predict a picklist value?** Not directly. Predictions are binary or numeric. Model each outcome you care about as its own checkbox, and accept that you then have several predictions to maintain. **How often does the model retrain?** On a schedule, and you can rebuild manually. Retrain after any material process change, because a model trained on the old sales stages describes a company that no longer exists. **Can I use the score in a [validation rule](https://trailassembly.com/validation-rule-vs-flow/)?** You can reference the field, but do not. Blocking a save on a probabilistic score produces arguments you cannot win and no audit trail of why the record was refused. --- Source: https://trailassembly.com/salesforce-einstein-prediction-builder/ Trail Assembly — independent Salesforce write-ups.