Machine Learning
Machine learning is the discipline of building software that learns patterns from data instead of being explicitly programmed with rules.
Definition
Machine learning is the discipline of building software that learns patterns from data instead of being explicitly programmed with rules. In Salesforce, machine learning shows up across the Einstein platform: classifying cases by topic, scoring opportunities by win probability, recommending the next best action, detecting duplicate records, forecasting pipeline, and dozens of smaller features that surface predictions inside the standard UI. Most of these run on managed ML models that Salesforce trains and operates; some run on customer-trained models built with Prediction Builder or Einstein Discovery.
Machine learning is the umbrella; large language models, predictive models, classification models, embedding models, and recommendation models are categories underneath it. The Salesforce conversation often blurs ML and LLM together because the recent product investment has gone heavily into generative AI, but the predictive and classification ML features that have been in Sales and Service Cloud for years still drive significant business value and follow the older ML lifecycle of training on labeled data, evaluating on holdouts, and retraining on a schedule.
Why ML in Salesforce is bigger than the LLM headlines suggest
Where Salesforce uses ML today
ML is embedded across the Salesforce product. Sales Cloud ships Einstein Opportunity Scoring, Einstein Lead Scoring, Einstein Forecasting, and Einstein Account Insights. Service Cloud ships Einstein Case Classification, Case Routing, Article Recommendations, and Reply Recommendations. Marketing Cloud ships Send Time Optimization and Einstein Engagement Scoring. Data Cloud uses ML for identity resolution and calculated insights. Commerce Cloud uses it for product recommendations and search ranking. Each feature has its own ML model behind it, often invisible to the user, surfacing as a score, a label, or a ranked list rather than as an "AI" badge.
Supervised vs unsupervised vs reinforcement
Most Salesforce ML is supervised: the model trains on examples with known labels (closed-won opportunities for win prediction, manually categorized cases for case classification). The training data tells the model what right looks like. Unsupervised ML finds patterns without labels (clustering customers by behavior, anomaly detection in transactions). Reinforcement learning trains an agent to take actions through trial and reward; it is rare in core Salesforce but shows up in some recommendation tuning. Knowing which type you are working with shapes the data preparation: supervised needs clean labels, unsupervised needs representative samples, reinforcement needs a feedback signal.
The training-evaluation-deployment lifecycle
An ML model goes through a fixed lifecycle. Train on historical labeled data. Evaluate on a holdout set the model has not seen. Pilot in production with a small user or queue subset. Roll out broadly. Monitor accuracy in production. Retrain on schedule or on drift detection. Retire when no longer useful or when replaced. Each phase has its own work. The phase most teams underinvest in is monitoring; a model that worked great at launch can degrade for a quarter before anyone notices, by which point the trust dividend is gone. Schedule monitoring before broad rollout; do not treat it as a future task.
Training data quality and the rule that everything else follows
ML models are bounded by the quality of their training data. A case classification model trained on inconsistent labels learns inconsistent classifications. An opportunity scoring model trained on opportunities where reps wrote "Closed Lost" for "wrong contact" and "no budget" and "competitor won" produces scores that mean nothing because the underlying labels meant nothing. Investing in label quality (decision rules for what counts as won, what counts as lost, who can mark which) pays back more than tuning the model architecture. Salesforce-managed models try to compensate with normalization but cannot fix bad labels at the source.
Bias, fairness, and the responsibility you cannot delegate
Every ML model inherits the bias of its training data. A model trained on historical hiring data that favored one demographic produces predictions that perpetuate that bias. The Salesforce Trust Layer and Einstein Discovery's bias detection tools surface measurable bias in model outputs across protected attributes (age, gender, race when applicable). The detection is the first step; the action is the customer's responsibility. Removing biased features from training does not always remove the bias because correlated features can encode the same signal. The honest framing: ML reflects the world it was trained on, and ensuring the world you train on is the world you want is a sustained discipline.
ML vs LLM: where the line is
LLMs are a subset of ML, specifically a class of neural networks trained on text. The line that matters in practice: LLMs are generative (they produce new text), most other ML is discriminative (it produces a score, category, or rank). LLMs are non-deterministic (the same prompt produces slightly different responses), most other ML is deterministic. LLMs cost per call (tokens), most other ML costs per training run and is nearly free per inference. The Salesforce design pattern is to use LLMs for generation and discriminative ML for scoring and ranking. Mixing the two (using an LLM to score an opportunity) is usually slower, more expensive, and less accurate than using a fit-for-purpose scoring model.
Where to learn ML for a Salesforce career
Most Salesforce work using ML does not require building models from scratch. Trailhead modules on Einstein Discovery, Prediction Builder, and the AI Associate trail give the right amount of background for admins and developers using managed models. Custom model work (Einstein Discovery story building, custom Apex prediction calls) benefits from external ML fundamentals (statistics, basic Python, the Andrew Ng Coursera course or equivalent). Architects benefit from understanding the lifecycle and the bias question well enough to advise customers, even when they will not personally train a model. The depth required scales with the work; the floor is recognizing what good and bad ML practice looks like in production.
How to use ML in a Salesforce org without overpromising
The successful pattern is: pick the right ML feature for the business decision, validate label quality, pilot on a small subset, monitor relentlessly. The failed pattern is: turn on a managed ML feature because it sounds impressive, watch users distrust the scores, turn it off six months later.
- Identify the business decision the ML feature will inform
Write one sentence describing the decision the model output will drive. Route this case to that queue. Prioritize this lead. Forecast this opportunity. If you cannot finish the sentence, you are not ready to turn the feature on.
- Pick the matching Einstein feature or build custom
Most decisions map to a shipped Einstein feature. Check Einstein Lead Scoring, Opportunity Scoring, Case Classification, etc. first. Build custom (Prediction Builder, Einstein Discovery) only when no shipped feature fits.
- Audit the underlying labels
For supervised models, the training data labels drive everything. Pull a sample of historical records and confirm the labels are consistent. Inconsistent labels produce a model that learns the inconsistency.
- Train (or let Salesforce train) and review evaluation metrics
Salesforce-managed models show evaluation metrics in the feature setup page. Custom models show metrics in Prediction Builder or Einstein Discovery. Review against the business decision, not against generic accuracy.
- Pilot on a small user or queue subset
Two to four weeks of pilot data tells you whether the model performs against real users. Holdout evaluation does not. Roll out broadly only after pilot data confirms.
- Schedule monitoring and a retraining cadence
Set a recurring report that tracks the model output against ground truth (when ground truth becomes available). Schedule retraining monthly for new features and quarterly for stable ones. Add drift alerts.
- Document the model owner and review date
Write down who owns each ML feature and when it gets reviewed next. Models accumulate without ownership and become operational liabilities.
Managed Einstein feature (no training required) or custom-built (Prediction Builder, Einstein Discovery). Drives setup work and flexibility.
Supervised (needs labeled training data), unsupervised (finds patterns without labels), reinforcement (learns from feedback). Drives data preparation.
Salesforce-managed models retrain automatically on a schedule. Custom models retrain when you trigger it. Monthly for new, quarterly for stable.
Einstein Discovery surfaces bias metrics across protected attributes. Critical for any model that affects users (hiring, lending, recommendations to customers).
Named individual responsible for the model's continued accuracy and the next scheduled review date. Required for accumulation discipline.
- Label quality drives everything in supervised ML. A model trained on inconsistent labels produces inconsistent predictions. Audit labels before evaluating the model.
- Monitoring is the most under-invested phase. A model that worked at launch can degrade for a quarter before anyone notices. Schedule monitoring before broad rollout.
- Bias is inherited from training data. Removing biased features does not always remove bias because correlated features can encode the same signal. Bias detection is a sustained practice, not a one-time check.
- Using LLMs for scoring tasks is usually worse than fit-for-purpose discriminative models. Slower, more expensive, less accurate. Pick the right model type for the job.
- Holdout evaluation rarely matches production performance. Two to four weeks of pilot data tells you what users actually experience.
Trust & references
Cross-checked against the following references.
- Salesforce Einstein overviewSalesforce
- Salesforce AI strategySalesforce
Straight from the source - Salesforce's reference material on Machine Learning.
- Einstein Platform OverviewSalesforce Help
- Einstein DiscoverySalesforce Help
- Prediction BuilderSalesforce Help
Hands-on resources to go deeper on Machine Learning.
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 is Machine Learning?
Q2. What Einstein features use ML?
Q3. Can admins build custom ML predictions without data science?
Discussion
Loading discussion…