Einstein Autofill Setup
Einstein Autofill Setup is the Salesforce Setup page where administrators configure Einstein's ability to suggest or automatically populate field values on records based on machine learning predictions.
Definition
Einstein Autofill Setup is the Salesforce Setup page where administrators configure Einstein's ability to suggest or automatically populate field values on records based on machine learning predictions. The feature reads patterns from existing records in the org (an Account's Industry usually tracks with its Company Size and Website), trains a model on the available signal, and offers Einstein-suggested values inline on record-create and record-edit pages.
The autofill itself can run in two modes: suggested (the field shows a pre-filled value the user can accept, edit, or clear) or applied (the value is written automatically when the record saves). Most teams start in suggested mode to validate accuracy before letting the platform write fields without confirmation. Autofill is one of several Einstein features that compete for the same problem of cutting data-entry overhead; Einstein Case Wrap-Up, Einstein Activity Capture, and the newer Setup with Agentforce all reduce manual typing through different mechanisms.
Why a feature this useful is also this often misconfigured
Where Einstein Autofill Setup lives
Setup, Einstein, Einstein Autofill. The page lists every standard and custom object that supports autofill (most sObjects do, with exceptions for high-volume objects like LiveAgentSession). For each object, you pick which fields to enable autofill on, the mode (suggested vs applied), and the training data scope (filter the historical records the model learns from). Autofill respects field-level security and validation rules; a value Einstein predicts can still fail to save if a validation rule rejects it, which is desirable but occasionally surprising to admins who expected the prediction to flow through.
How the model learns from your data
Autofill trains a model per field per object using the historical records that have the target field populated. For Account.Industry, the model looks at every Account where Industry is set, learns which other field values correlate, and uses those correlations to predict Industry on new Accounts where it is blank. A minimum of around 1,000 records with the target field populated is required to produce a model worth deploying. Below that, the predictions are noisy enough that suggested mode wastes user attention and applied mode produces wrong data. The page surfaces the training record count before activation so admins do not enable autofill on under-trained fields.
Suggested vs applied mode and the trust ladder
Suggested mode shows the Einstein-predicted value pre-filled in the field with a small icon indicating it is a suggestion. The user can accept (do nothing), edit (overwrite), or clear it. Applied mode writes the predicted value on save without showing the suggestion to the user. The right rollout is to start in suggested for at least four weeks, watch the accept rate per field, and only switch to applied on fields with accept rates above 85 percent. Skipping the suggested phase produces data quality complaints because users never see the predictions and learn to distrust the field.
Field eligibility and which fields fit autofill
Picklists, multi-select picklists, currency, number, boolean, and date fields are eligible. Text fields are eligible but rarely useful because text predictions tend to be too generic. Lookup fields are not eligible because the model has no way to choose between candidate records. Formula fields are not eligible because they are derived. Required fields are eligible but the autofill does not override the required flag; users still cannot save without a value if they clear the suggestion. The best candidate fields are picklists with 3 to 20 values that correlate with other record data; the worst are free-text fields with high cardinality.
Permissions, audit, and what users see
The Einstein Autofill permission set governs who sees suggestions on which objects. Without the permission, the user sees the field unfilled even though the model has a prediction available. Audit fields on the underlying object capture who ultimately wrote the value; a value written by autofill in applied mode shows the user who saved the record, not "Einstein", which is occasionally confusing in record history. Setup, Einstein Autofill Insights surfaces per-field accept rate, average prediction confidence, and prediction volume. Pull this report monthly to spot fields drifting in accuracy.
Common rollout mistakes
Four mistakes recur. Enabling autofill in applied mode without piloting suggested mode produces wrong data and user complaints. Enabling autofill on fields with fewer than 1,000 historical training records produces noisy predictions. Enabling autofill on text fields produces generic suggestions users ignore. Skipping the Insights review means quality drift goes unnoticed for months. The fix in each case is procedural rather than technical: start small, validate, expand, monitor. The feature works well when run with discipline and produces a flood of bad data when run without.
Relationship to other Einstein features
Autofill, Case Wrap-Up, Activity Capture, and Setup with Agentforce all reduce manual data entry but apply at different points in the workflow. Autofill predicts fields at create or edit time. Case Wrap-Up suggests closure-time field values. Activity Capture writes Activity records from email and calendar automatically. Setup with Agentforce builds metadata from natural-language requests. Choosing among them is not exclusive; an org typically runs three or four of these together. The overlap is rare because each one writes different fields on different objects.
How to enable Einstein Autofill without producing dirty data
The path that works: pick one high-value field, enable in suggested mode, watch accept rate for four weeks, switch to applied if accept rate is above 85 percent, expand. The path that fails: enable autofill on every field in applied mode and discover the data quality problem two months later when reports start looking off.
- Identify one or two high-value pilot fields
Pick a picklist field where data entry is currently spotty and where the value correlates with other record data. Account.Industry and Opportunity.Type are common pilots.
- Confirm training data volume
Open Setup, Einstein Autofill. Check that the pilot field has at least 1,000 historical records with the field populated. Below that, predictions are noisy and the pilot will fail.
- Enable autofill in suggested mode
Toggle autofill on for the pilot field, mode Suggested. The model trains in the background; predictions appear on the next record-create or record-edit after training completes.
- Pilot with one team for four weeks
Five to ten users in the pilot team see suggestions on the field. The rest of the org sees the field unchanged. Watch the Insights report for accept rate, edit rate, and clear rate.
- Decide on applied mode based on accept rate
Above 85 percent accept rate, applied mode is safe. 60 to 85 percent, leave in suggested. Below 60 percent, the field is wrong for autofill; revert and pick a different field.
- Expand to additional fields one at a time
Repeat the pilot pattern per field. Resist the urge to batch-enable; per-field rollout catches field-specific issues before they become org-wide complaints.
- Schedule the monthly Insights review
Pull Einstein Autofill Insights monthly. Watch for fields whose accept rate drops over time. Drift signals retraining is needed or the underlying data shape has shifted.
Per-object list of fields autofill is active on. Roll out one at a time, not in batches.
Suggested shows a pre-filled value the user can accept or edit; applied writes the value on save without showing it. Start with Suggested.
Filter the historical records the model trains on (date range, record type, owner). Useful when older data has different patterns than current data.
The Einstein Autofill permission set that grants users access to suggestions on the enabled fields.
How often the model retrains against fresh data. Defaults to weekly; can be tuned for fields where the underlying pattern shifts faster.
- Applied mode without piloting suggested mode produces wrong data that users never see. Always pilot suggested first.
- Fewer than 1,000 historical records with the field populated produces noisy predictions. The page warns; admins still ignore the warning regularly.
- Text fields rarely benefit from autofill. Predictions are too generic to be useful, and users learn to ignore them, which trains poor habits.
- Validation rules still apply to autofilled values. A predicted value that fails a validation rule blocks the save, which is desirable but confusing if undocumented.
- Record history shows the saving user, not Einstein, as the author of an applied autofill value. Compliance teams may want a separate audit trail signal documented.
Trust & references
Cross-checked against the following references.
- Salesforce Einstein overviewSalesforce
- Autofill referenceSalesforce
Straight from the source - Salesforce's reference material on Einstein Autofill Setup.
- Einstein AutofillSalesforce Help
- Einstein Autofill SetupSalesforce Help
- Einstein Platform OverviewSalesforce Help
Hands-on resources to go deeper on Einstein Autofill Setup.
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 Einstein Autofill Setup need to work effectively?
Q2. How does the Einstein Trust Layer relate to Einstein Autofill Setup?
Q3. What technology powers Einstein Autofill Setup in Salesforce?
Discussion
Loading discussion…