Data Spaces and Why They Matter More Than Orgs

Over the past few years, I have had many conversations with leaders, architects, and engineers across the Salesforce ecosystem. These discussions often start with operational challenges or platform constraints, but they quickly shift toward a deeper question: how should we structure data and applications for the next decade of Salesforce? The answers are changing. New patterns are emerging. Data Spaces are part of that shift.

This is still early work. Only a small number of organisations have explored Data 360 in a modern way. But the direction of travel is becoming clear, and the lessons from these conversations are worth sharing with anyone thinking about where their architecture should evolve next.

Why orgs still matter

The Salesforce org is not going away. It remains the core boundary for application logic. It holds metadata, sObjects, automation, permissions, and the operational processes that run the business. Nearly every leader I speak with still relies on the org as the anchor of their estate.

What is changing is how teams think about using orgs. A growing number of architects are beginning to experiment with smaller, more focused application orgs. These orgs behave like containers for bounded contexts. One might handle Sales. Another might handle Service. Another might host a specialist workflow for Claims or Retail Execution. Geography is another common source of process difference which can now be accommodated with this additional flexibility.

This is not widespread yet, but I am seeing it more often in large enterprises trying to regain control of sprawling metadata, conflicting automation, and monolithic orgs that have become too hard to change.

Importantly, Data Spaces do not replace orgs. When a business needs application autonomy, a new org is still the right choice. But orgs no longer need to carry the burden of data governance as well. That responsibility is starting to move into the data layer.

Why Data Spaces exist

Many of the leaders I speak with face the same pressure: they need to separate data for legal, operational, or regional reasons. Historically, the solution was to create more orgs. It worked, but it also produced complexity, duplicated data, and heavy integration.

Data Spaces provide a new option. A Data Space is a boundary inside Data 360 that defines how data is governed, where it resides, and which identity rules apply. It lets organisations separate data without creating new application orgs. This distinction matters. It keeps application concerns and data concerns cleanly separated.

This is still experimental for most teams. But those who are exploring Data Spaces are finding that they give them more flexibility and clearer governance than relying solely on org boundaries.

DMOs and the shift in architectural thinking

One of the biggest changes I have seen in recent discussions is the movement toward defining enterprise meaning at the data layer, not the application layer. Data Model Objects in Data 360 make this possible. A DMO establishes the canonical definition of an entity such as Customer or Product. It separates the logical identity from where the data is stored or how it is used in each org.

This does not replace sObjects. sObjects still drive transactions and user experience in each application org. But DMOs give architects a way to unify meaning across those orgs. When combined with Data Spaces, they provide controlled, governed segmentation without fragmenting that meaning.

These are early patterns, but they represent a strong architectural direction.

How Data Spaces can simplify multi-org estates

Organisations with multiple orgs often describe the same issues: duplication, uneven data quality, and integrations that grow more complicated every year. In the conversations I have with engineering leaders, these challenges are usually a sign that the org is being asked to do too much.

Data Spaces and DMOs offer a way to rebalance the architecture. Orgs remain focused on applications. Data 360 becomes the enterprise backbone. DMOs standardise meaning. Data Spaces enforce governance and residency. Identity resolution and lineage occur where they belong: in the data layer.

None of this is simple. It requires investment and change. But it is helping some organisations reduce complexity without losing autonomy.

When to use Data Spaces vs separate orgs

A practical pattern is emerging from the teams exploring these ideas:

·      Use an org when you need an application boundary.

·      Use a Data Space when you need a data boundary.

If metadata, automation, or permissions differ, create an org. If governance, residency, or identity policies differ, create a Data Space.

This approach keeps the architecture modular and avoids unnecessary fragmentation.

A shared exploration

These patterns are not mature yet. They will evolve as more teams work with Data 360, Data Spaces, Data Cloud One, and multi-org container models. My hope in sharing this thinking is to encourage others to join the exploration. The best architectural breakthroughs in the Salesforce ecosystem have always come from collaboration between practitioners. The shift toward a layered, data-centred architecture is no different.

If you are experimenting with Data Spaces, multi-org design, or enterprise DMOs, I would love to hear your experiences. Together, we can shape a clearer, more sustainable architectural landscape for the next generation of Salesforce delivery.