What it does

Customer Insights - Data adds a Customer Profile lookup column to the Dataverse tables it ingested from the linked environment, and stamps it during unification so a contact, lead or account row points at its unified profile. From there a model-driven app form can show profile attributes, measures and calculated activities next to the record a seller or agent is already looking at.

Key facts

• The lookup column is Customer Profile, schema name msdynci_lookupfield_customerprofile, added to the source Dataverse tables.
• Stamping happens as part of the unification run, under a task called CustomerId Backstamping Hydration. You watch it under Settings > System > Status.
• It runs incrementally by default. A full run happens on the first execution, when there's no successful Merge result to work from, or when the customer profile schema has changed.
• Source tables must come from the same Dataverse environment that Customer Insights is linked to, ingested via the Microsoft Dataverse connector (recommended) or the Power Query Dataverse connector.
• The primary key used at ingestion must be the table's real primary key — contactid, leadid and so on. An alternative key won't do.
• B2C environments only. Not supported for B2B.
• Not supported when the environment uses your own Azure Data Lake Storage.
• Writes are performed by the InsightsAppsPlatform (IAP) service account, and they update LastModifiedOn on every stamped record.
• The Customer Card Add-in, the old way of doing this, is deprecated and unavailable for new installs. Microsoft's replacement guidance is to customise apps against the Dataverse data directly.
• The Power Apps connector for Customer Insights exists as a preview alternative — Customer, UnifiedActivity and Segments tables, 100 calls per 60 seconds, delegation only on indexed profile fields and on ActivityId/CustomerId for activities. Microsoft points at the Dataverse route instead.

When to use / skip

If the client's stated benefit case includes "sellers see the full customer picture in Sales" or "agents see lifetime value in Customer Service", you need this. It is the sanctioned path now that the Customer Card Add-in is gone, and it's far less work than building a bespoke retrieval layer. Skip it if the environment is B2B or on bring-your-own-lake, because it isn't available and you'll need to build the join yourself against msdynci_customerprofiles. Also skip it if the client only wants profile data in reporting — a Power BI model over Dataverse doesn't need a stamped lookup, and you avoid a large write against production records for nothing.

Configuration decisions

• Which Dataverse tables get ingested into Customer Insights in the first place, since only those get a lookup.
• Whether you show profile data by adding the lookup to forms, by embedding a related-records subgrid, or by copying selected measures onto native columns for filtering and rollups.
• Which measures and calculated activities are actually worth surfacing on a form — every one you add is a field a seller has to interpret.
• Whether workflows, plugins and Power Automate flows on the affected tables should be suppressed during the first unification run.
• Filtering attributes on existing plugin registrations, so the lookup update doesn't fire business logic that has nothing to do with it.
• Security: who can see the profile lookup and what happens when a user has access to the contact but not to the profile data behind it.

Gotchas

• The first run touches a lot of records. Every workflow, plugin, flow and integration listening for changes on contact will fire. Disable triggers before it runs, then re-enable, and tell the client's integration owners in advance.
• LastModifiedOn moves on stamped rows. Anything downstream doing "records modified since" delta sync will pull the whole table on the next cycle. This catches out marketing sync jobs and data warehouse loads regularly.
• Audit history picks up the IAP service account writing to records nobody touched. If the client audits contact changes for compliance reasons, warn them before, not after.
• A schema change to the unified profile forces a full run, so the bulk-update event isn't a one-off you can plan around once.
• Ingesting a Dataverse table with anything other than its true primary key looks fine during unification and then silently produces no linking.
• People still ask for the Customer Card Add-in by name because it's in old decks and old partner material. It's deprecated and closed to new installs — don't get talked into hunting for the solution file.

Consultant notes

• Demo this on a contact form with two or three measures rather than twenty attributes. The conversation you want is about which numbers change a seller's behaviour, not about how much you can display.
• Schedule the first unification run after linking is enabled for a quiet window, and treat it like a bulk data load with the client's integration team on notice.
• If the client is B2B, say so early and price the alternative — a manual join against the profile table — rather than discovering the limitation in build.
• Check before go-live that plugin filtering attributes exclude the lookup field, and that no one has built a business rule triggered by it.
• Push back on requests to make the lookup editable or to let users reassign a profile. It's maintained by the unification process and anything users do to it will be overwritten.

---

Worth another look if B2B support or bring-your-own-lake support ever appears for automatic linking.