Connections, third-party consent and API access

What it does

A connection is the admin-owned link between a Customer Insights - Data environment and another service — an export destination or a third-party enrichment provider. Creating one includes an explicit data privacy and compliance agreement, because it is the point at which personal data leaves the product. The APIs tab under Permissions is the other egress route, and it is gated the same way: admin only.

Key facts

Only administrators can create connections. Contributors can use one, but only if the admin sets Choose who can use this connection to allow it.
Two kinds: export connections (data out to another service) and enrichment connections (third-party data in, for example Leadspace). Once created, an enrichment connection is available to admins and contributors alike.
A connection is reusable — one connection can back several exports or enrichments rather than one per destination.
Creating a connection requires agreeing to the data privacy and compliance terms with an explicit I agree. That agreement puts responsibility for having the right consent, and for the third party's privacy and security posture, on the client, not on Microsoft.
Contributors building an export see only the connection's display name and type. They cannot open it or see the credentials, which is why the display name has to say what it is and where it goes.
Secrets can be held in Azure Key Vault rather than in the connection itself, via the Use Key Vault option.
A connection cannot be deleted while anything depends on it. Exports have to be removed or detached first, and enrichments deleted or deactivated.
Removing a connection is the documented way to stop the data flow to that third party immediately.
Other Microsoft services you connect to must sit in the same organisation.
API access is enabled separately at Settings > Permissions > APIs, which generates primary and secondary subscription keys. Application access needs an Entra app registration with the Dynamics 365 AI for Customer Insights permission — user_impersonation for delegated, api.access for server-to-server — plus admin consent, and for server-to-server the app registration must also be added as a user in Settings > Permissions.
Microsoft's own guidance is to query through the Dataverse APIs rather than the Customer Insights APIs, on filtering, throughput and latency grounds. C#, Node and Python client libraries exist for the Customer Insights API if you do need it.

When to use / skip

You will create connections on every project that exports anything, so the question is not whether but who owns them. The split the product enforces is a good one: admins own the destination and the credentials, contributors own what gets sent and how often. Adopt that as the operating model rather than fighting it.

Third-party enrichment connections deserve more scepticism. The consent agreement is not a formality — you are sending customer personal data to another company, and someone at the client has to be able to say which lawful basis covers it. If nobody can name that person in the workshop, do not build the connection yet.

On the API: reach for Dataverse first. The Customer Insights API is the right answer for a narrow set of cases — driving product operations programmatically, or an existing integration already built against it — but for reading profiles, segments and measures, Dataverse gives you a better query surface and the client's developers already know it.

Configuration decisions

Which connections are shared with contributors and which stay admin-only.
Whether secrets live in the connection or in Key Vault, and who administers that vault.
A display-name convention that survives someone else reading it in a year — service, environment, purpose.
Who at the client signs off each third-party data transfer, and where that sign-off is recorded.
Whether the Customer Insights API is enabled at all, and if so which app registrations hold keys.
Whether integration reads go via Dataverse or the Customer Insights API, decided once rather than per developer.

Gotchas

Only admins create connections, so a contributor asked to build an export will get as far as the destination picker and stop. Sequence the work so connections exist first.
Delete order bites: you cannot remove a connection while an export or enrichment references it, and the error does not name the dependent object helpfully.
After copying an environment's configuration, connections come across but need reauthenticating, and dependent exports and enrichments stay dormant until you turn them back on.
The consent checkbox is clicked by whoever happens to be doing the setup — often the consultant. Make sure the client understands who is actually accepting that obligation.
API subscription keys are environment-scoped and are regenerated as a pair; rotating them without telling the integration owner takes their integration down cleanly and immediately.
Server-to-server API access needs the app registration added as a user in Permissions as well as consented in Entra. Missing that second step produces an authorisation failure that looks like a consent problem and is not.

Consultant notes

Build and share the connections during setup, before the contributors start on exports, and document each one's purpose in the display name.
Put the third-party consent decision in front of the client's data protection contact in writing. Never let it be something the delivery team clicked through.
Recommend Key Vault for anything with a rotating secret — it is the difference between a scheduled rotation and an outage.
If developers ask for API access, ask what they are querying first. Most of them want Dataverse and do not know it yet.
Before go-live, list every active connection and every issued API key with a named owner. That list is the first thing anyone asks for in a security review.

Worth another look if the Customer Insights API picks up documented rate limits, or if connection consent moves into a central Power Platform control.