The End of the sObject Era: Why the Future Belongs to DMOs

For nearly two decades, the sObject has defined how Salesforce data is structured and understood. Each org contained its own data model. The Account, Contact, and Opportunity tables formed the backbone of CRM. Architects could count on them as the primary source of truth for business information.

That model worked well when most enterprises ran a single org. Today, many no longer do. Multiple clouds, multiple orgs, and multiple systems all hold overlapping views of the same entities. This is where the limits of the sObject era start to show. The next generation of Salesforce architecture needs a broader foundation. It needs a unified data model that spans systems, not just objects within one org.

The limits of the sObject truth

An sObject describes data within a single org. It is perfect for transactions but narrow for enterprise data. As soon as data exists in multiple orgs or platforms, the sObject loses its authority. Each org becomes a silo with its own record of the customer, product, or asset. Integration can synchronise those records, but it cannot turn them into one coherent truth.

Many teams have built custom integration layers or adopted master data management (MDM) tools to compensate. These approaches help, but they are external patches. They sit outside the Salesforce platform and duplicate many of its concerns: identity, governance, and sharing. They also introduce latency and complexity.

The real answer is not better synchronisation. It is a different definition of truth. That is where Data 360 enters.

Data 360 and the rise of the DMO

Data 360 introduces an enterprise data layer that sits above individual orgs. It unifies customer and operational data across systems through what can best be described as Data Model Objects, or DMOs. Salesforce does not use that exact term, but the concept is implicit. A DMO represents the canonical definition of a business entity in Data Cloud. It aggregates data from multiple sources, reconciles identities, and maintains governance and lineage.

Each DMO separates logical meaning from physical storage. The “Customer” DMO, for example, can combine CRM records, commerce profiles, and service interactions into one composite view. Data 360 handles the mapping, identity resolution, and activation. This design moves the center of gravity for enterprise data away from individual orgs and into a governed, unified layer.

In practice, sObjects remain critical for transactional processes. A Sales org still needs Opportunity and Quote objects to function. A Service org still needs Case and Entitlement. What changes is that those objects now consume and contribute to DMOs rather than define them. The distinction between the two can even become invisible, as Data 360 synchronises canonical attributes back into orgs. For single-org customers, nothing changes. For enterprises with multiple orgs, this shift is transformative.

Multi-org design and identity

Multi-org design has always been a difficult architectural question. It affects security, data residency, autonomy, and cost. The introduction of Data 360 adds another dimension: where to anchor shared truth.

In a DMO-centric architecture, each org participates in a wider ecosystem. It no longer needs to hold the master record of a customer. Instead, Data 360 becomes the home of that record, and orgs subscribe to it. Identity resolution happens once, centrally. Downstream systems align to that single definition. This approach reduces duplication and the need for complex sync jobs between orgs.

The trade-off is control. Some business units may prefer their own local instance for compliance or autonomy reasons. The Salesforce provisioning guidance acknowledges this. The ideal pattern is to create the smallest number of Data 360 instances possible, usually one Home Org and several Companion Orgs. But in regulated environments, multiple instances may still be needed. Architects must balance centralisation against flexibility.

The key is to make the DMO model explicit and consistent, even when there are several Data 360 instances. Each instance should represent the same canonical definitions and mappings. That ensures interoperability and avoids fragmentation at the data model layer.

Interoperability and data movement

The Data 360 interoperability patterns provide several options for how data flows between systems. Architects can choose ingestion (copying data into Data 360), zero-copy federation (querying external data without duplication), or hybrid approaches. Each comes with trade-offs in cost, latency, and complexity.

An ingestion model simplifies analytics and identity resolution but increases storage cost and governance scope. Federation keeps data in place but requires strong identity matching and performant connectors. The hybrid approach—copying key attributes while federating large or volatile datasets—is becoming the most practical for large enterprises. It aligns with how DMOs are used as logical entities rather than as complete physical replicas.

The decision point is not purely technical. It is strategic. Data 360 becomes the enterprise foundation for analytics, AI, and activation. The pattern chosen affects everything from performance to compliance. Architects should lead those discussions early, in collaboration with data governance and platform teams.

Trade-offs and practical realities

Adopting a DMO-centric architecture changes team boundaries as well as technical ones. Integration developers, data engineers, and Salesforce admins need to work from the same canonical definitions. That requires shared design artifacts and governance processes.

Performance considerations also differ. Some operations that were instantaneous in a local org may now depend on Data 360 pipelines or API calls. Designing for eventual consistency becomes important. The benefits—cleaner integration and enterprise visibility—usually outweigh the trade-offs, but they must be understood.

Cost is another factor. Running Data 360 introduces new infrastructure and licensing considerations. Architects should quantify the value of de-duplication, reduced integration overhead, and data clarity when making the case. The goal is to achieve enterprise consistency, not to replicate all data for its own sake.

Finally, governance must evolve. DMOs only deliver value when their definitions and mappings are managed properly. That means disciplined stewardship, version control, and clarity on which orgs can update which attributes. Without this, Data 360 risks becoming just another data silo.

Guidance for architects

1. Define canonical entities. Identify customers, products, assets, or locations that span multiple systems. Model them in Data 360 as DMOs.

2. Map existing orgs. For each org, map key sObjects and fields to those DMOs. Decide whether each field is mastered in the org or in Data 360.

3. Choose an interoperability pattern. Balance ingestion, federation, and hybrid approaches based on cost, latency, and governance.

4. Plan your provisioning strategy. Where possible, use a single Home Org with Data Cloud One. If multiple instances are needed, keep the DMO definitions aligned.

5. Design for participation. Treat each org as a participant in a shared model. Refactor integrations to publish and subscribe to Data 360 rather than synchronise records directly.

6. Embed governance. Create clear ownership for each canonical entity and its mappings.

7. Evolve incrementally. Start with one or two entities that deliver visible business value, then expand as patterns mature.

The architectural shift

The sObject is not disappearing. It remains vital to the runtime of each Salesforce application. But it no longer defines the entire architecture. In the enterprise context, the center of truth moves upward to the DMO layer. This does not erase the sObject model; it reframes it within a larger system of meaning.

This shift represents more than a data integration pattern. It is a change in how Salesforce architectures are conceived. The org is no longer the universe. It is a node in a network of data. The DMO, or unified data entity, becomes the connective tissue of the enterprise.

Architects who embrace this model will design systems that are cleaner, more scalable, and ready for an AI-driven future where data meaning—not data storage—defines the value of the platform.