What it does

When you create a Customer Insights - Data environment you pick where the data physically sits: Microsoft-managed Customer Insights storage behind the linked Dataverse environment, or your own Azure Data Lake Storage Gen2 account. The choice covers ingested data, unified profiles, segments and output tables, and it decides what integration options you get afterwards.

Key facts

• The choice is made at the Data storage step of environment creation. Options are Customer Insights storage (Microsoft's recommendation) or Azure Data Lake Storage Gen2.
• Bring-your-own-lake requires hierarchical namespace enabled on the storage account, and the account must be in the same Azure region as the Customer Insights environment.
• The admin setting it up needs Storage Blob Data Contributor or Storage Blob Data Owner on the storage account, or on the customerinsights container specifically.
• Data lands in a container named customerinsights. Multiple environments pointed at the same account get separate folders named ci_environmentID.
• You can connect by Azure subscription or by account key. Account key means someone has to update the connection by hand every time keys rotate.
• The target storage account cannot be changed later. Getting this wrong means a new environment.
• Mapping is one Dataverse organisation to one Azure Data Lake Storage account. No sharing an account across Dataverse orgs.
• With bring-your-own-lake, automatic linking of customer profiles into Dataverse is not supported. That's the feature that puts a Customer Profile lookup on your contact and lead records.
• Getting msdynci_ output tables into Dataverse from your own lake needs the Dataverse data sharing option, which was still preview and requires security groups, PowerShell and a Permissions identifier supplied during environment creation.
• Data sharing with Dataverse doesn't work if the storage account sits behind a firewall. Private Link covers the ingestion path, not that.
• Environment type also gets fixed here: sandbox environments don't run scheduled refreshes.

When to use / skip

Take Microsoft-managed storage unless you have a specific, written reason not to. The bring-your-own-lake path costs you the automatic profile linking, adds a preview-grade PowerShell dance to get output tables into Dataverse, and buys you very little on a typical delivery. The genuine reasons to go your own way are: the client's data governance team requires that customer data lives in a storage account they own and audit, there's an existing lakehouse or Synapse estate that needs the raw and unified layers in place rather than exported, or a sovereignty requirement that a managed store doesn't satisfy on paper. Customer-managed keys and Key Vault integration are separate features — a client asking for "our own encryption keys" doesn't necessarily need their own lake, and conflating the two is a common way to talk yourself into the harder architecture for no benefit.

Configuration decisions

• Managed storage or bring-your-own-lake, made before the environment exists and effectively permanent.
• Region, which must line up with the storage account and, if the client runs several environments on one account, across all of them.
• Which Dataverse environment to install into — an existing one that doesn't already have Customer Insights, or a new one provisioned as part of the install.
• Subscription-based connection versus account key, and if account key, who owns the rotation runbook.
• Whether to enable Dataverse data sharing at creation time if you're on your own lake, because retrofitting it is not a settings toggle.
• Sandbox versus production, remembering that no scheduled refresh on sandbox changes how you demo and how you test the refresh-driven integrations.

Gotchas

• Everything about this step is a one-way door. Storage account, region, Dataverse environment, environment type — all fixed at creation. Treat the environment creation session as a design review, not an admin task.
• Teams pick bring-your-own-lake for control, then discover months later that the Customer Profile lookup they wanted on contacts was never available to them. Establish whether that linking is in scope before the storage decision, not after.
• A firewalled storage account passes the ingestion tests and then fails the Dataverse sharing setup. Find out about the client's network posture early.
• Installing through the Power Platform admin center is the default and recommended route, and it does not surface the bring-your-own-lake and data sharing options. If the design needs them, you must create the environment from Customer Insights instead.
• Granting the Administrator role in Customer Insights - Data also gives that person System Administrator in Dataverse. Security teams do not always expect this.
• Account key connections rot quietly. The refresh fails on a Sunday with an authentication error that reads like a Customer Insights fault.

Consultant notes

• Get this decision made and signed off in the design phase, in writing, with the loss of automatic profile linking spelled out. It's the cheapest risk mitigation on the whole project.
• If the client's ask is "we want our data in our lake for analytics", ask whether an Azure Data Lake or Fabric export from a managed environment does the job. Nine times out of ten it does, with none of the constraints.
• Provision one throwaway environment first and prove the ingestion and unification path before creating the one you'll keep.
• Check with the client's Azure team who owns the storage account lifecycle. A resource group cleanup that removes a customerinsights container is not a recoverable event.
• Before go-live, confirm the storage region and the Dataverse region actually match what the client's data residency statement says — auditors ask, and the answer needs to be evidenced.

---

Worth another look once Dataverse data sharing from your own lake goes GA and drops the PowerShell setup.