SfSkills Domains Docs GitHub

Home / admin / einstein-discovery-setup

einstein-discovery-setup

Use this skill when an admin needs to create an Einstein Discovery story in CRM Analytics Studio, configure prediction definitions, deploy writeback fields, set up what-if analysis, or manage model refresh and activation.

Open the skill folder on GitHub


Einstein Discovery Setup

Use this skill when an admin configures Einstein Discovery: creating stories, deploying prediction definitions, writing predictions back to Salesforce fields, enabling improvements for what-if analysis, and managing model refresh and activation. It covers the admin path and the metadata that carries a prediction definition between orgs. For programmatic scoring and REST endpoints, use agentforce/einstein-discovery-development.

Grounding note: the Einstein Discovery admin guide pages are on help.salesforce.com, which did not fetch for this pass, and the Einstein Discovery REST API guide did not fetch either. The grounded source here is the Metadata API Developer Guide's DiscoveryAIModel, DiscoveryGoal, and DiscoveryStory types. Wizard and UI behavior carried from earlier versions of this skill is marked UNVERIFIED where it is stated as fact.


Before Starting


Questions to Ask Before Configuring

Ask these before creating a story. Each one traces to a gotcha in references/gotchas.md.

QuestionWhy it mattersWhat a good answer addsWhat proper configuration adds over just doing it
"Which outcome are we predicting, and which fields are only known after it happens?"Leakage fields inflate accuracy and produce useless live scores (gotcha 7)The outcome field and an excluded-variables listA model whose scores hold up on open records
"Do different segments (region, product line) behave differently enough to need their own model?"One prediction definition holds up to ten active models; the first matching filter wins (gotcha 2)Segment filters in priority orderPredictions from the right model for each record
"Which fields are sensitive, and could any act as a proxy for a protected attribute?"Model fields carry isSensitive and isDisparateImpact flags (gotcha 6)A reviewed list of sensitive and disparate-impact fieldsA bias review on record before scores reach users
"Who sees the prediction field, and where?"The writeback field lives on the record; its visibility follows field-level security (gotcha 8)The permission sets and layouts that show the scoreScores visible to the right users from day one
"Will this prediction be moved between orgs with metadata?"Removing pushbackField from the goal file deletes the field (gotcha 1); models are not authored in metadata (gotcha 3)A retrieve-then-deploy procedure that never drops the fieldPromotions that do not destroy the writeback field or its history
"Who reviews and activates each refreshed model, and how is accuracy judged?"terminalStateFilters define when an outcome is final for accuracy monitoring (gotcha 5)An owner, a cadence, and a terminal-state definitionModel drift caught by a person, not discovered by users

What a proper setup adds over "just deploying the story": the right model scores each segment, sensitive fields are reviewed, the writeback field survives every deployment, and someone owns each refresh.


Core Concepts

Story, model, and prediction definition

ConceptMetadata typeKey facts
StoryDiscoveryStoryThe analysis Einstein Discovery builds from a dataset
ModelDiscoveryAIModel (.model file plus -meta.xml, in the discovery folder)algorithmType, predictionType, modelFields, status; "write operations for DiscoveryAIModel objects are generally not supported"
Prediction definitionDiscoveryGoal (.goal, in the discovery folder)subscribedEntity, outcome, deployedModels, pushbackField, pushbackType, terminalStateFilters, active

Algorithms and prediction types

DiscoveryAlgorithmType values are Best (tournament model), Glm (generalized linear model), Gbm (gradient boosting machine), Xgboost, and Drf (random forest). DiscoveryPredictionType values are Regression, Classification (binary), MulticlassClassification, and Unknown. Earlier versions of this skill said Einstein Discovery chooses only between regression and GBM; the metadata enumeration lists more algorithms. UNVERIFIED (2026-10-03): which algorithms the story wizard offers, and whether the admin chooses or the tournament picks, is help-only.

Writeback (pushback) fields

pushbackField is the "automated writeback field for predictions. A custom field on the Salesforce object specified in subscribedEntity." pushbackType "must be set to AiRecordInsight"; Direct is reserved. UNVERIFIED (2026-10-03): earlier versions of this skill said the field is read-only, updates only through bulk scoring or explicit API calls (never on record save), and is limited to three per object. Test record-update behavior in a sandbox before telling users how fresh scores are.

Model refresh and activation

Each deployed model has an active flag, and the prediction definition has its own active flag. UNVERIFIED (2026-10-03): that a completed refresh leaves the new model inactive until an admin activates it in Model Manager is help-only, but the operating rule is the same either way: someone reviews accuracy and decides which model is active.


Common Patterns

Pattern 1: End-to-end story deployment with writeback

When to use: Score open Opportunities with a win prediction and show the score on the record page.

How it works:

  1. Create the story from the Opportunity dataset with the outcome and explanatory variables; exclude fields populated only after close.
  2. Review model fields flagged sensitive or disparate impact before deploying.
  3. Deploy the model to a prediction definition on Opportunity, with a writeback field and improvements if what-if suggestions are wanted.
  4. Grant field-level security on the writeback field and add it to the page layout or the record page.
  5. Score existing records and spot-check values.
  6. Retrieve the DiscoveryGoal into source control so the field and model mapping are versioned (see references/metadata-examples.md).

Pattern 2: Segmented prediction definition

When to use: Win drivers differ by region.

How it works: Deploy one model per region to the same prediction definition, each with a filter on the region field. Put the most specific filters first, because the first matching model scores the row. Keep a final model with no filters as the catch-all ("no filters indicates that the model matches all input rows"). Stay within ten active models.


Decision Guidance

SituationRecommended ApproachReason
No CRM Analytics licenseEinstein Prediction BuilderEinstein Discovery needs CRM Analytics
Different behavior by segmentSeveral deployed models with filters in one prediction definitionUp to ten active models; first matching filter wins
Promote to productionRetrieve DiscoveryGoal, deploy it, keep pushbackFieldRemoving pushbackField deletes the field
Need model authored outside SalesforceModel Manager upload, not metadataUserUpload source type is not supported in the Metadata API
Fresh scores at a business momentDeveloper scoring API (agentforce/einstein-discovery-development)Admin path is not built for event-driven scoring
Accuracy monitoringDefine terminalStateFiltersAccuracy compares predictions with outcomes that have reached a terminal state

  1. Confirm prerequisites. CRM Analytics license, admin permissions, target object, outcome field, and the excluded-variables list.
  2. Create and review the story. Build it in Analytics Studio, exclude leakage fields, and review fields flagged sensitive or disparate impact.
  3. Deploy the prediction definition. Choose segments and filters (up to ten active models), the writeback field, and improvements; define terminal-state filters for accuracy monitoring.
  4. Make the score visible. Grant field-level security on the writeback field, add it to layouts, and score existing records.
  5. Put it under source control. Retrieve the DiscoveryGoal (and the models it references) with package.xml; never deploy a goal file that has lost its pushbackField.
  6. Run refresh as an operation. Name the owner who reviews each refreshed model's metrics and decides which model is active, then rescore.

Review Checklist


Salesforce-Specific Gotchas

The deep versions, with sources, live in references/gotchas.md.

#GotchaOne-line consequence
1Removing pushbackField from goal metadata deletes the fieldA careless deploy destroys the score field
2Up to ten active models; the first matching filter winsBadly ordered filters send rows to the wrong model
3DiscoveryAIModel write operations are generally not supportedHand-authored model files do not deploy
4pushbackType must be AiRecordInsightOther values are reserved or unsupported
5Accuracy needs a terminal-state definitionMonitoring compares against outcomes that are not final
6Model fields carry sensitive and disparate-impact flagsBias review skipped if nobody reads them
7Leakage fields inflate accuracyLive scores are poor despite great training metrics
8Writeback visibility and refresh behavior are help-only claimsTest before promising score freshness

Output Artifacts

ArtifactDescription
Story configuration summaryOutcome, explanatory variables, excluded leakage fields, sensitive-field review
Prediction definitionDiscoveryGoal with models, segment filters, writeback field, terminal-state filters
Writeback field visibilityField-level security and layout placement
Model refresh runbookOwner, cadence, accuracy review, activation, rescoring

Package files