What Databricks CustomerLake Means If You Run Salesforce

For a joint estate, the useful question was never which one wins. It’s which system holds which slice of customer context, and whether the connection between them is one deliberate pattern or an accumulation of point fixes made under deadline. 

Salesforce keeps CRM attributes, consent state, service history and every workflow a seller or service agent touches. CustomerLake becomes a candidate for the signal that never reaches the CRM at all: product telemetry, web and app behaviour, loyalty transactions, commerce events and third-party enrichment. 

That data already lands in the lakehouse, and until now acting on it meant either exporting to a separate CDP or commissioning bespoke pipelines. 

Two decisions can’t be deferred: which system anchors identity for which identity space, and how consent state flows in both directions. 

Get those wrong and you’ve built two competing customer views with a compliance problem in between. 

What Databricks CustomerLake Brings to Salesforce Customers 

Foundational Data 360 Zero Copy capabilities and the MuleSoft Agent Scanner for Databricks are generally available now. 

Data 360 enhancements, Slack Genie App general availability, agentic search and MCP-driven integrations are rolling out through the second half of 2026 and beyond. 

CustomerLake itself has no announced GA date, though Gartner’s first take on the launch expects general availability in the fourth quarter of 2026 or early 2027, and advises scheduling evaluations in the third quarter of 2026, a window that is nearly closed. 

One more timing to be noted. Dreamforce runs from 15 to 17 September, and it is the obvious place for Salesforce to update the Data 360 roadmap and say more about the Databricks partnership. Anything announced there may move the dates above. 

It will not move the structural question of which platform holds which slice of customer context. That is the part worth deciding now. 

That split is what you plan against. Zero Copy is something to build on this quarter, while federated identity mapping is something to design toward rather than design around. 

What Should Salesforce Customers Consider Before Adopting CustomerLake? 

If you’re running Salesforce and Databricks together, the important question isn’t simply whether CustomerLake is another CDP option. 

The bigger question is how Salesforce CRM, Data 360 and the Databricks lakehouse should divide responsibility for customer data. That means looking closely at: 

• Customer identity: Which platform should anchor identity for each customer data domain?  

• Consent management: How should consent and preference data move between Salesforce and Databricks?  

• Data governance: Can existing governance policies remain consistent across both platforms?  

• Data activation: Which customer signals should trigger action in Salesforce?  

• Integration architecture: Are existing pipelines ready for the increased movement of data and activity between the two platforms?  

• Customer context: Which platform should own which part of the overall customer view?  

These decisions become especially important as organisations bring more Salesforce data, external data and operational data together. 

The goal shouldn’t be to duplicate customer data across platforms simply because both systems can store or process it. The goal should be to give each platform a clear job and make the connection between them deliberate. 

What Does Databricks CustomerLake Mean for Your Salesforce Strategy? 

The two vendors most enterprises run together chose the same day to overlap in one place and integrate more deeply in another, which is less a contradiction than a fair description of how the market works now. 

It also means the integration layer between CRM and lakehouse deserves more architectural attention than it usually gets. That points at something worth doing before any of these ships. 

Look at the Salesforce-to-Databricks integration you already run. If it’s nightly batch jobs someone built years ago, agentic workloads arriving on both sides are the prompt to redesign it once, properly, rather than patch it for another two years. That work pays off whatever you decide about CustomerLake.