Chris Vizes Data visualisation and more

What's the difference between a DLO, DMO and CIO in Tableau Next/ Data Cloud

Why Use DMOs Instead of DLOs in Salesforce Data Cloud

As organisations build richer data foundations in Salesforce Data Cloud, one design choice often appears: should you connect directly to Data Lake Objects (DLOs), or introduce a Data Model Object (DMO) layer on top?

At first glance, using DLOs seems simpler. You already have the data. Why add another layer? The answer lies in flexibility, maintainability, and long-term efficiency. Abstracting your data through DMOs may take a little more work up front, but it saves significant time and frustration later.

Understanding DLOs and DMOs

Before deciding which to use, it’s worth clarifying what each represents.

Data Lake Objects (DLOs) are the raw building blocks of Data Cloud. They reflect ingested data in its original structure, whether that data comes from Salesforce, an external database, or a data lake. DLOs are schema-driven and close to the source, which makes them ideal for rapid access to raw information.

Data Model Objects (DMOs), on the other hand, sit one layer above. They provide a curated, business-friendly view of the data. DMOs can reference one or more DLOs, apply transformations, standardise field names, and enforce consistent relationships across entities. In short, they act as a stable contract between your data storage and the teams or systems consuming it.

If DLOs are your pantry full of ingredients, DMOs are the prepared meal — organised, refined, and ready to use.

The Temptation to Go Direct

Many teams start by connecting directly to DLOs. It feels efficient: less setup, fewer layers, and immediate access to data.

However, what seems simple in the short term can become a major maintenance burden over time. Every dashboard, app, or automation that connects directly to a DLO becomes tightly coupled to its structure. If a field name changes, if data moves to a different source, or if the schema evolves, all of those dependencies must be updated manually.

In Salesforce Data Cloud, editing or recreating objects is rarely straightforward. Each change requires redeployments, permission updates, and regression testing. Without an abstraction layer, even a minor modification can ripple across your entire data estate.

Why DMOs Are Worth the Effort

Introducing DMOs between your DLOs and end consumers brings several long-term advantages.

1. Decouple Storage from Consumption

DMOs provide a buffer between your data storage and the systems or people using it. If you ever need to move data from one lake to another, update a schema, or modify ingestion logic, you can do so behind the DMO. Reports, apps, and integrations remain stable, because their connection doesn’t change.

This decoupling gives your architecture agility. You can modernise or optimise your data pipelines without breaking what sits on top of them.

2. Simplify Maintenance

Working directly with DLOs can make even simple edits painful. DMOs reduce that complexity by centralising change management. Instead of editing ten downstream systems, you update the DMO definition once.

For teams that iterate frequently or experiment with new data sources, this approach makes a real difference. It reduces deployment effort, testing cycles, and operational risk.

3. Enforce Consistent Business Logic

DMOs also help align business definitions. By modelling entities such as Customer, Product, or Transaction once, you ensure that every connected system uses the same version of the truth.

This consistency matters for analytics and compliance alike. When “revenue” or “active customer” is defined differently in different reports, trust erodes. DMOs eliminate that ambiguity by enforcing shared logic at the data model level.

4. Support Governance and Quality Control

Because DMOs act as the interface to data, they are an ideal place to implement validation, enrichment, and auditing rules. You can track lineage, apply quality checks, or mask sensitive fields in one place.

For organisations subject to data protection or financial regulations, this centralisation helps maintain control and transparency without adding complexity to every consuming system.

A Real-World Example

Imagine your marketing team connects their dashboards directly to a DLO that holds customer engagement data from an S3 bucket. Initially, everything works perfectly.

A few months later, the data engineering team decides to restructure the storage. They rename several fields and migrate the source from S3 to Snowflake for better performance.

If your dashboards connect directly to the DLO, every one of them will break. Each visualisation, transformation, and automation referencing those fields must be updated.

With a DMO, nothing changes for the marketing team. The DMO definition absorbs the structural changes behind the scenes. Dashboards continue working without interruption, and users stay focused on insights rather than technical fixes.

Designing DMOs Effectively

To get the most out of DMOs, treat them as part of your long-term data design.

These principles turn DMOs into a robust layer that supports both technical evolution and business reliability.

The key lesson is simple: resist the urge to link directly to your raw data. Data Cloud is designed for scale and flexibility, and DMOs are central to achieving both.

By introducing an abstraction layer, you make your data architecture more resilient to change, easier to maintain, and more consistent across the organisation. The short-term effort of building DMOs pays back many times over in reduced rework and greater trust in your data.

In Salesforce Data Cloud, the best practice is clear: think in layers, not links.

Written on October 6th, 2025 by Chris Meardon
Share

You may also enjoy: