Predictive AI in Data 360: native models, bring-your-own-model, and getting a score to actually do something

The whole industry is pointed at generative AI right now, and it’s easy to forget that most of the money a data platform makes is still made by an unglamorous number: the probability this customer churns, the propensity this lead converts, the predicted value of this account. Those are predictive models — regression and classification, not language generation — and they’ve been quietly running businesses for a decade. Data 360 (the platform formerly known as Data Cloud, renamed at Dreamforce in October 2025) is a genuinely good place to build and run them now, precisely because the unified profile you assembled for agent grounding is the same clean, wide table a predictive model wants to train on.

But “Data 360 does predictive AI” hides two very different products under one Model Builder roof, and a naming collision with the generative side that trips up almost everyone. This post is the honest map: the native AutoML path and its real limits, the bring-your-own-model path to a SageMaker, Vertex, or Databricks endpoint and what “zero-copy” actually means when you look closely, why the Einstein Trust Layer protects none of this, and — the part most teams underinvest in — how a prediction score stops being a number in a table and starts changing what your business does.

First, separate predictive from generative

Model Builder (the tool surfaced from what was Einstein Studio, now under AI Models / Model Builder in Data 360) handles both predictive and generative models, and that single fact causes more confusion than any technical detail below. When someone says “we bring our own model to Salesforce,” they might mean two completely different things:

• Bring your own LLM — pointing Prompt Builder or an agent at your own GPT, Claude, or Gemini for generative work. That’s a different surface with different wiring, and we mapped it in bring your own LLM to Salesforce. It is not this post.
• Bring your own predictive model — connecting a trained regression or classification model (churn, propensity, LTV, lead scoring) hosted on your ML platform for inference against Data 360 data. That is this post.

Keep those in separate boxes and everything downstream gets clearer — including, as we’ll see, which governance layer applies. Conflate them and you’ll cite the wrong limits, the wrong costs, and the wrong safety story.

The native path: AutoML on a DMO

The fastest way to a prediction in Data 360 is to build the model there. You point Model Builder at a Data Model Object (DMO) — your unified customer profile, ideally — choose the outcome you want to predict and the fields that predict it, and an AutoML process trains and picks the best model. No notebook, no data export.

What it can do, precisely, matters because the boundaries are real:

• Two problem types only: binary classification and numeric regression. Will this customer churn (yes/no)? What’s this account’s predicted next-quarter spend (a number)? That’s the native envelope. Multiclass classification is not supported natively — if you need to predict one of several categories, that’s a bring-your-own-model job.
• The outcome variable has rules. For regression it’s any numeric field. For binary classification it’s a text field with exactly two distinct values. Pick the target and the predictor columns from the DMO; you can train on everything or on a filtered set of records.
• AutoML picks the algorithm. For binary classification Salesforce trains candidates like Random Forest and Logistic Regression; for regression, Random Forest and Linear Regression; XGBoost is available too (at a lower row ceiling). The process tests and selects the best performer, and hands you a scorecard — AUC for classification, R-squared for regression — to judge whether the model is worth deploying.

There are training-data requirements you’ll hit if your data is thin. Per Salesforce’s published considerations, a native model wants a floor of a few hundred rows with known outcomes (and, for binary classification, a healthy count of rows for each of the two outcome values so it isn’t learning from a handful of positives), scales up into the millions of rows (with a lower cap when XGBoost is in play), and needs at least a couple of predictor columns up to a few dozen. Confirm the current exact figures in the live docs before you design around them — these limits move between releases, and a model that silently won’t train because you’re under the row floor is a frustrating way to learn one. The unglamorous truth underneath: the model is only as good as the unified profile it trains on, which is why the identity resolution and data-transform work that produces one clean row per customer is the actual prerequisite, not the modeling.

Feature engineering is a Data 360 job, not a modeling afterthought

A predictive model doesn’t want raw source rows; it wants features — customer tenure, average order value, days since last login, a normalized engagement score. In Data 360 those are exactly the artifacts you already have tools for. Calculated insights compute the metrics (lifetime value, purchase frequency, recency) across your unified estate; data transforms flatten, bucket, and reshape source data into model-ready columns. The pipeline reads: unify into DMOs → engineer features with insights and transforms → train on the resulting wide table.

This is worth stating because teams treat feature engineering as a data-science step they’ll do “later, in the model.” In Data 360 it’s a data step you do first, in the platform, with the same governed definitions your segments and agents already use — which means your churn model’s “engagement score” is the same engagement score the rest of the business reads, not a private redefinition that quietly disagrees with the dashboard.

Bring your own model: what “zero-copy” honestly means

If native AutoML is too narrow — you need multiclass, a deep-learning model, a custom feature pipeline, or you simply already have a mature model in your ML platform’s registry — you connect it with BYOM. The officially supported homes are Amazon SageMaker, Google Cloud Vertex AI, and Databricks (backed by Mosaic AI Model Serving), plus generic custom endpoints.

Mechanically, a BYOM connection is a model endpoint: a URL that invokes your hosted model. In Model Builder you register it — endpoint name, URL, an auth header (typically a bearer token) — and then you define the input and output schema, mapping predictor fields from the scoring DMO to the model’s expected inputs, with data types that have to match. At inference, Data 360 sends a request and gets a score back. A representative contract looks like this:

// Request Data 360 sends to your SageMaker/Vertex/Databricks endpoint
{
  "instances": [
    { "tenure_months": 34, "avg_order_value": 82.50,
      "days_since_last_login": 12, "support_tickets_90d": 3 }
  ]
}

// Response your endpoint returns, mapped back to the output DMO
{
  "predictions": [
    { "churn_probability": 0.78, "model_version": "churn-v4" }
  ]
}

On SageMaker this endpoint is typically a real-time inference endpoint fronted by API Gateway and a Lambda that transforms the JSON between Salesforce’s contract and the model’s — a detail worth knowing because that translation layer is where a surprising amount of BYOM debugging happens.

Now the phrase everyone repeats and few examine: zero-copy. It’s true and it’s marketing, and the gap between those matters. Zero-copy means Data 360 does not bulk-export or replicate your training/scoring dataset into the ML platform — the model is invoked in place, record by record, over a secure API. It does not mean nothing crosses the wire. At inference, the feature values in each request payload are transmitted to your external endpoint — to your AWS, GCP, or Databricks region. That’s a real data-residency and compliance consideration you own: the bulk data stays put, but the features you score on leave Salesforce’s boundary for yours on every call. State that plainly to your security team; “the data never leaves Data 360” is the shorthand that gets architects in trouble when someone reads the network diagram.

The governance surprise: the Trust Layer doesn’t cover this

Here’s the point that will save someone a bad answer in a security review. The Einstein Trust Layer — the masking, the zero-retention agreements, the toxicity and audit pipeline everyone invokes as the reason Salesforce AI is safe — is a generative-AI construct. It governs LLM prompts and responses. It does not sit in front of a predictive regression or classification endpoint.

So when a BYOM article claims “all inference routes through the LLM Gateway and the Trust Layer,” it’s describing generative bring-your-own-LLM, not predictive BYOM. For a SageMaker churn model, there is no Trust Layer masking your feature payload — the governance is whatever you build around the endpoint: the auth on the URL, the network path, the region, your provider’s data handling. Claiming Trust Layer protection for a predictive model is the kind of confident, wrong statement this platform’s naming practically invites, and it’s exactly the sort of thing that surfaces in an audit at the worst moment. Predictive inference security is your architecture, not Salesforce’s checkbox.

Getting a score to do something

A model that produces a beautiful AUC and changes nothing is a science project. The operationalization step — turning a score into an action — is where predictive projects earn their keep, and Data 360 gives you several paths.

A prediction job runs records from a source DMO through the model and writes results to a new output DMO — and note what lands there: the prediction result plus the primary key, not a copy of the source features. Those jobs run in two modes, and the choice sets both cost and freshness:

• Batch — score on a schedule or on demand. Right for populating a segment overnight, back-testing, or a weekly propensity refresh.
• Streaming — re-score a record automatically when its input fields change, for near-real-time reaction. Right when the whole point is to catch a churn signal the moment it appears, not tomorrow.

From the output DMO, the score flows into the business through familiar surfaces:

• Flow — add an Action node in the Data Cloud category to invoke the model as an invocable action, or read the output DMO, and branch on the score. A Data 360-triggered flow or Data Action can fire the instant a score crosses a threshold — churn risk over 0.7 creates a save-offer task in Service Cloud and writes the score back to the Account.
• Segmentation — build an audience of “high churn risk, high value” directly on the prediction.
• Agentforce grounding — a Predictive Model action lets an agent invoke an Einstein Studio predictive model mid-conversation, mapping inputs from the record automatically, so a service agent can reason with the customer’s live churn probability instead of guessing. This is the bridge from the predictive world to the agentic one: the model computes the number, the agent acts on it.

That last path is why predictive AI is quietly more relevant in the Agentforce era, not less. An agent grounded on a governed semantic layer knows what your metrics are; a Predictive Model action lets it know what’s likely to happen. Both beat a confident guess.

Costs, drift, and the trade-offs nobody demos

Two operational realities to price in before you build.

Cost has two shapes. Native models and prediction jobs consume Data 360 credits, metered against work done — scoring a hundred-thousand-row DMO is a hundred-thousand-row operation, and streaming re-scores continuously, so the same real-time reflex that inflates every Data 360 bill applies here too (the mechanics are the same ones in the pricing and credits guide; verify current per-operation rates on the live rate card). BYOM adds a second invoice entirely: you pay your cloud provider to host and run the endpoint, on their meter, outside Salesforce billing. A “free” open-source model on a SageMaker endpoint you keep warm is not free.

Models don’t maintain themselves. A Data 360 model is not auto-updated — you retrain or re-run to refresh it, and there’s no substitute for a human deciding when. Treat drift as your responsibility: a churn model trained on last year’s behavior degrades as behavior shifts, and Data 360 won’t tap you on the shoulder about it. For BYOM there’s a second maintenance burden — the input/output schema must stay in sync with the DMO; change the profile’s shape and a BYOM mapping can break until you re-register it.

Which sets up the honest native-versus-BYOM call. Use native when the problem is binary or regression, the team wants clicks over code, and you value everything living inside Data 360’s governance. Use BYOM when you need multiclass or an algorithm native doesn’t offer, you already run mature models with your own MLOps, or your data scientists want their own toolchain — accepting the external endpoint’s latency (a network hop per score), its separate bill, and the schema-sync discipline. Most mature estates end up with both: native models for the standard, high-volume scores, BYOM for the specialized ones.

What to actually do

Start from the unified profile, not the model — a predictive model is only as good as the one-row-per-customer DMO under it, so the identity resolution, transforms, and calculated insights come first. For a standard churn or propensity score, try the native path: it’s fast, it’s governed, and binary-classification-or-regression covers most of what businesses actually predict. Reach for BYOM deliberately, when native’s limits (no multiclass, fixed algorithms) genuinely bind — and go in clear-eyed about the second cloud bill, the inference-time data egress that “zero-copy” doesn’t eliminate, and the schema you now have to keep in sync. Whichever path, budget as much attention for operationalization — the prediction job, the threshold, the flow, the agent action — as for the model itself, because a score nobody acts on is the most common way these projects fail. And do not tell your security team the Trust Layer has predictive inference covered; it doesn’t, and that governance is yours to build.

Get that right and Data 360 becomes the place where your predictive and generative AI finally share a foundation — the same unified data grounding the agent also training the churn model, the model’s score flowing into the agent’s reasoning. If you’re standing up predictive models on Data 360 and want the native-versus-BYOM call, the operationalization, and the honest security story made deliberately, talk to us — building the data foundation so models train on truth and their scores actually change what happens is exactly the work we do.

Understanding the basics

Can Salesforce Data 360 build a predictive model without an external tool?

Yes. Data 360’s Model Builder (the tool surfaced from the former Einstein Studio) can train a predictive model natively on a Data Model Object with a no-code AutoML flow — you pick the outcome and predictor fields and it trains and selects the best algorithm. Native modeling supports binary classification and numeric regression only; it does not support multiclass classification natively, which is one of the main reasons to bring your own model. It scores classification with AUC and regression with R-squared.

What does bring-your-own-model (BYOM) zero-copy actually mean in Data 360?

BYOM connects an externally trained predictive model — hosted on Amazon SageMaker, Google Vertex AI, or Databricks — as a model endpoint that Data 360 calls for inference. “Zero-copy” means Data 360 doesn’t bulk-export or replicate your dataset into the ML platform; the model is invoked in place, record by record. It does not mean nothing is transmitted: the feature values in each inference request are sent to your external endpoint in your cloud region, which is a real data-residency consideration you own. The bulk data stays; the features you score on cross the wire.

Does the Einstein Trust Layer protect predictive model inference?

No. The Einstein Trust Layer is a generative-AI construct — it governs LLM prompts and responses with masking, zero-retention agreements, and toxicity and audit checks. It does not sit in front of a predictive regression or classification endpoint. For a bring-your-own predictive model, the governance is whatever you build around the endpoint: authentication, network path, region, and your ML provider’s data handling. Claims that “all BYOM inference routes through the Trust Layer” describe generative bring-your-own-LLM, not predictive BYOM.

---

Standing up churn, propensity, or lifetime-value models on Data 360 and weighing native AutoML against a SageMaker, Vertex, or Databricks endpoint — and want the operationalization and the security story right? Talk to us. Building the data foundation so predictions train on truth and their scores actually drive action is the work we do.