Custom models with Azure Machine Learning

What it does

This is the bring-your-own-model path. You build a batch inference pipeline in Azure Machine Learning, connect the workspace to Customer Insights - Data, and register a workflow that feeds unified data into the pipeline and writes the results back as an output table against customer profiles.

Key facts

Configured from Insights > Predictions > Create, on the Custom model (Azure Machine Learning v2) tile. The connection itself is set up first under Settings > Connections.
Permissions are split: Owner or User Access Administrator on the Azure ML workspace, plus Admin or Contributor in the Customer Insights - Data environment. One person rarely holds both, which is a scheduling problem more often than a technical one.
You need an Azure ML workspace with pipeline support and an associated Azure Data Lake Storage Gen2 account.
Only batch inference pipelines are supported. A model published from the SDK cannot be wired in directly — it has to be wrapped in a batch inference pipeline first.
Datasets must be registered in the workspace, must be tabular, and must be in .csv format, with dataset parameters configured through Designer or the SDK.
Pipeline data import and export uses the Blob Storage datastore type, and the Export Data module has to parameterise both the datastore and the path so Customer Insights can point at it.
Pipeline output is limited to a single tabular .csv file.
The connection display name has to start with a letter and use only alphanumeric characters and underscores.
During workflow setup you supply a model name, the output table name, a primary key and the Customer ID attribute, then map every input attribute.
All attributes must be mapped. Optional attributes aren't supported — the model contract is fixed at the pipeline, and to change it you change it in Azure ML, not in Customer Insights.
Data sources using incremental refresh are not supported as inputs to custom models.
Workflows are managed from the My predictions tab: edit, refresh on demand (they also run on the scheduled refresh), or delete. Deleting the workflow leaves the output table in place.
Results land in Data > Tables > Output and are readable over the API with OData filters.
Machine Learning Studio (classic) support ended on 31 August 2024. Anything still referencing it needs rebuilding on Azure ML pipelines.

When to use / skip

Reach for this when the out-of-box models genuinely don't fit — a propensity model for a product the standard models can't express, a risk score with regulatory requirements about how it's calculated, a model the client's data science team already owns and validates. It's also the only sensible route when the client has an existing model estate and Customer Insights is being introduced as the activation layer rather than the modelling layer.

Skip it for anything the out-of-box models can approximate. The integration is real work: Azure subscription, workspace governance, storage, pipeline build, a second set of permissions, and an ongoing owner for the pipeline. Clients underestimate all of it because the tile in the UI looks like the other prediction tiles.

Also skip it if there's no data science capability on the client side after go-live. A custom model with nobody to retrain or explain it is a liability that outlives the project.

Configuration decisions

Who owns the Azure ML workspace and its cost, since it sits outside the Customer Insights licence and outside most CI project budgets.
Which unified tables and attributes form the model input contract. Every one of them must be mapped, so the contract needs to be settled before the pipeline is finalised.
Output table name, primary key and the Customer ID attribute that ties results back to profiles.
Datastore and output path parameterisation in the pipeline, agreed with whoever manages the storage account.
Whether the workflow runs on the environment's scheduled refresh or only on demand, and how that lines up with when the source data actually lands.
How model outputs are consumed downstream — segments, measures, exports — and whether consumers need the raw score or a derived flag.

Gotchas

The incremental refresh restriction catches mature environments. If the client has already tuned their large data sources for incremental refresh, those sources can't feed a custom model without rework.
No optional attributes means a schema change on the input side breaks the workflow. Column added, column renamed, mapping fails.
The .csv and single-output-file constraints rule out pipelines that were designed to emit parquet or multiple tables. Discover that before the data science team builds anything.
Deleting a workflow leaves the output table behind. It stops refreshing but stays visible, and stale prediction data with a familiar name is a genuine reporting hazard.
The split permission model stalls builds. Get both sets provisioned in the same change request rather than discovering the gap mid-sprint.
Studio (classic) is gone. Any inherited artefact referencing it is a rebuild, not a migration.

Consultant notes

Estimate this as an integration workstream with its own Azure dependencies, not as a variant of configuring an out-of-box prediction. The two look similar in the UI and cost nothing alike.
Get the input attribute contract signed off early, in writing. Mapping every attribute with no optionals means late schema changes are expensive.
Demo the output table and an OData query rather than the setup wizard. Stakeholders care that the score reaches profiles and can be exported; the pipeline plumbing is not a demo.
Push back on custom models proposed before the out-of-box ones have been tried on the client's actual data. Run the standard model, read the grade, then decide.
Before go-live, confirm named ownership for pipeline retraining and for the Azure ML workspace itself. This is the handover item most likely to be missed.

Worth another look if Microsoft publishes a documented Fabric route for custom models, or if the .csv and single-output-file limits are relaxed.