Get Out of My Dreams Head and Into My Car Diagram

If you’ve ever found yourself singing Billy Ocean songs to yourself as you tried to explain a Data 360 data model using only your hands and a determined facial expression, this post is for you! Data Model Objects (DMOs) and their relationships live in Data 360 in a way that’s technically documented, but not exactly easy to look at. Sure, the Data Model tab gives us some cute bubbles to look at, but it’s not exactly easy to navigate or dive into how individual fields are mapped.

Enter Diagramforce, a free tool for visualizing Salesforce data models as clean, shareable diagrams. The tricky part is getting from the data model from only living in Data 360 (and your head) and into a usable JSON file that Diagramforce can understand. I recently went through this process for a client project and came across several wrong ways to do this before finally landing on a solution. Thankfully it’s one that is easily repeatable and works well as a first CLI project.

Why Use Diagramforce At All?

When I first asked my client if they had any documentation or diagrams showing how each of the DMOs in their system were connected, they pointed me towards the Data Model graph mode, where we quickly discovered that we can’t actually get the type of granular information we’re looking for from that visual. Don’t get me wrong, I do appreciate the high level overview of how each DMO is related to one another, but when I need to get a Data 360 specialist to dive into some field mapping issues with me, it’s not exactly a walk in the park to investigate if you don’t know the data model first hand. 

• Diagramming existing DMOs and relationships helps with future discovery documentation and knowledge transfers in the event that someone leaves the organization
• A visual representation of a data model is a lot easier for most people to understand, especially in comparison to a table of object API & field names
• Seeing your existing data model will help with change management in the future by allowing you to avoid breaking something you didn’t know was connected

Required Tools to Get Started

This should come as no surprise, but there are a few tools and access points that you’ll want to make sure you have before you dive into this project. 

• Salesforce CLI installed and authenticated to the target org (see below for more information on this process)
• PowerShell (this walkthrough uses it, but the same logic works in bash if that’s your preference)
• API access to the org’s DMOs — more on this below

All the Small Wrong Things

Before we dive into the way I made this work, you should know I didn’t get this right on the first or second try. Initially I wanted to retrieve the DMOs as metadata, the same way you’d retrieve a standard component using the CLI. Unfortunately, DataModelObject isn’t a registered metadata type in the CLI registry, so that failed.

Next, I tried to exchange the CLI’s API session token with a Data 360 tenant token, but that didn’t pan out either. The standard CLI session token doesn’t have the right OAuth scope needed for the exchange, and setting up a dedicated Connected App just for a single diagram felt like a lot of overhead for this task.

What Finally Worked

Although you won’t find the DMOs in your standard Object Manager, they are ordinary sObjects under the hood and answer to standard REST API calls the way any standard Salesforce object would. You’ll recognize them by the __dlm suffix. This means we can get to them and their relationships through the regular REST API describe endpoint, using whatever Salesforce org is specified in the CLI. The complete steps for this process are broken down for ease of reference below.

Authenticate Your Salesforce Org

You can connect Salesforce CLI to multiple Developer Orgs, Sandboxes, or Production, each one taking on their own Org Alias. You’re also able to set up a “Default” org that will be used in any commands that do not specify which connected org to use. The commands below will allow you to set an Org Alias, login, and set an org as the default org if desired.

Authentication in Production or Developer Orgs

sf org login web –alias my-org –set-default

Sandbox Authentication Script:

sf org login web –instance-url https://test.salesforce.com –alias my-sandbox –set-default

Edit the my-sandbox or my-org text to set your org alias. Try and keep this something short and memorable, if you add multiple orgs to the CLI you’ll need to reference this pretty regularly. The –set-default tag is optional,  and if you use it this org will be used as the default org when none is specified in a command. 

If your org is using Salesforce Enhanced Domains, you’re able to use the –instance-url command and include the login URL for your Enhanced Domain (checkout the Sandbox Authentication script for an example of this).

Create A Dedicated Folder

We’ll need to point PowerShell to a specific folder to find the scripts we’ll be running in future steps. This folder is also where the scripts will output documentation once they have finished running. Once you’ve created the folder, you’ll need to copy the path from the top of the File Explorer window, as shown below.

Download the Scripts for Extracting and Formatting

This method relies on 2 different scripts, one to extract the data from Data 360, and another to format it appropriately for Diagramforce. You’ll need both of these files stored in the folder you just created in the previous step. Once you’ve downloaded the scripts, you’ll need to replace any of the YourOrgAlias text with whatever org alias you entered when you authenticated the org earlier in this process. Without updating this, the script won’t know where it needs to pull the data from.

View the “Get Data 360 DMOs Script” here

View the “Convert to JSON Script” here.

Set Your Directory in PowerShell

Now that we have our folder created and our scripts saved, we need to tell PowerShell where it should look when we’re executing our next sets of commands. Inside of powershell, type the following:

cd [paste the file path we copied earlier here]

The “cd” command tells the system to change the directory to whatever file path comes afterwards, so for my example, I’d enter:

cd C:\Users\categ\DataCloud Diagrams

Enable Script Execution in PowerShell

By default, PowerShell blocks custom .ps1 scripts so we’ll need to run a command to bypass this restriction. This command only works to bypass things temporarily, so next time you go to run these scripts you’ll need to execute the same command.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Extract DMOs from Data 360

Now that your Salesforce org is authenticated, we’re ready to extract the DMOs from Data 360. Copy and paste the command below, being sure to replace the YourOrgAlias with whatever you set as your org alias in the previous steps.

.\Get-DataCloudDMOs.ps1 -TargetOrg YourOrgAlias

Getting it Ready for Diagramforce

Here’s where I got tripped up the most: you can’t upload the JSON file from the first script into Diagramforce as-is because it’s expecting a specific cell-graph structure. This structure helps to map out shapes with positions and ports, as well as the connections between them, and helps out with layout metadata. Rather than trying to build the structure blind, I was able to reference the JSON spec on Diagramforce’s GitHub and get the right structure for my data. You can run this script in the CLI with the following command:

.\Convert-DMOsToDiagramforce.ps1

This script reads the dmo-model.json stored in the same folder and creates a  diagramforce-import.json file that can be imported into Diagramforce successfully. Head over to Diagramforce and use File > Import JSON to import the diagramforce-import file. Once it’s loaded, you’ll be able to see all of the DMOs in your org, along with the relationships between them. You’ll likely need to spend some time organizing them and cleaning up some of the relationship names, but the end result is an excellent representation of the data model.

If you get a version mismatch warning on import, double check the appVersion value in the script against whatever the current Diagramforce release expects. You can find this information by checking out the GitHub repository for Diagramforce and checking what the most recent version of the platform is.

Things to Keep in Mind…

This is absolutely a first pass and not meant to be a finished product, but a step towards more accurate and usable documentation of Data 360. I also fought with 2 different LLMs to figure out the right approach and scripting to get this to work, but the code has been reviewed and this method has been tested in a few different orgs. A few other things worth mentioning:

• Diagramforce is a great tool, but the layout is still a simple drag and drop grid. You’ll likely need to spend some time rearranging after your import to make sure it’s legible.
• The scripts here all use “YourOrgAlias” as a placeholder. Make sure to update that text to match whatever your actual Org Alias is prior to running.
• If your org has multiple data spaces, you will need to filter the DMO list accordingly before converting – otherwise you’ll get a diagram of hot dog fingers everything, everywhere, all at once, defeating the purpose.
• Relationship names may not be end user friendly as they’re coming directly from the describe call in the script. You may want to relabel a few of them after import for clean documentation.

Another Data 360 Org? Time to Diagram!

If you’re working in Data 360 orgs regularly, it’s worth keeping both scripts (the extractor and the converter) in your toolkit rather than rebuilding them from scratch every time. Run the extractor whenever you land in a new org, run the converter, import into Diagramforce, and you’ve got a shareable diagram in less time than it used to take to attempt explaining the model verbally. Just be sure to update the “YourOrgAlias” name wherever it appears in the script so that it’s pointing to the right Salesforce org at runtime and you’ll be good to go.

Got a cleaner way to handle the layout step, or run into a different Data 360 quirk along the way? Drop it in the comments — I’d love to see how others are tackling this.

If you’ve spent years building Dynamic Lists and Engagement Studio programs, opening Data 360 for the first time can feel overwhelming. Unified Individuals, Segments, Calculated Insights, Data Spaces; it looks like a whole new world. But here’s the thing: it’s not.

At its core, segmentation hasn’t changed. You’re still trying to get the right message to the right person at the right time. What has changed is how much data you have to work with. Instead of building audiences from Prospect records and email engagement alone, Data 360 lets you layer in website activity, CRM data, opportunity history, subscription preferences, and more.

Here’s how to bridge what you already know with what you’ll find in Data 360.

The Biggest Mindset Shift: From Lists to Audiences

In Account Engagement, everything starts with a list.

• Need a webinar audience? Build a list.
• Need a re-engagement campaign? Build a list.
• Need a nurture track? Build a list.

In Data 360, you build reusable audience definitions instead. One segment can power multiple campaigns, journeys, and channels. You’re not creating a new list for every initiative. Think of it this way:

• Account Engagement: Campaign → Build List → Send Message
• Data 360: Define Audience → Activate Anywhere

The shift from campaign-specific lists to reusable audiences is the most important concept to internalize before you start building.

Terminology Translation

Before you build anything, here’s the cheat sheet:

Account Engagement	Data 360	What It Means
Prospect	Unified Individual	The person you’re marketing to
Dynamic List	Segment	A reusable audience built from defined criteria
Dynamic List Rules	Segment Criteria	The logic used to determine audience membership
List Member	Segment Member	Someone who qualifies for the audience
Prospect Activity	Engagement Data	Behavioral data used for targeting
Marketing List	Published Segment	A ready-to-use audience for activation
Score & Grade	Attributes	Signals used to identify high-intent audiences

Once that mapping clicks, the platform becomes a lot less intimidating.

Before You Build: Know Your Data

One thing that surprises most Account Engagement users is how much data is available in Data 360. Depending on your setup, you may have access to:

• Prospect data
• CRM data
• Email engagement
• Forms
• Landing Pages
• Website activity
• Preference center subscriptions
• Opportunity data
• External data sources

This is where Data 360 starts to shine.

In Account Engagement, we ask: “Who opened my email in the last 30 days?”

In Data 360, we ask: “Who opened my email in the last 30 days, visited my pricing page, and doesn’t currently have an open opportunity?”

That’s a fundamentally more sophisticated audience, and it’s exactly why organizations are investing in Data 360.

One important caveat: Not every org has the same data sources connected. Before building complex segments, take time to understand what’s actually flowing into Data 360 and how frequently it refreshes. Knowing your data inventory upfront will save you a lot of troubleshooting later.

Building Your First Segment 

Navigate to Data Cloud > Segments and select New. You’ll see four segment types:

Standard Segments are your go-to. These are the closest equivalents to Account Engagement Dynamic Lists and support the vast majority of marketing use cases. Start here.

Waterfall Segments let you prioritize audiences and prevent contacts from qualifying for multiple competing campaigns simultaneously — useful when running multiple offers at once.

Real-Time Segments evaluate audiences on demand for use cases requiring immediate qualification. Powerful, but they come with limitations.

Once you’ve selected Standard Segment, there are four ways to build your audience.

Option 1: Use the Visual Builder 

The Visual Builder offers the most flexibility and is where most marketers spend the majority of their time. The process is straightforward:

1. Create a New Segment
2. Select your Data Space (most often your Default Data Space)
3. Choose the object you want to segment on (most often Unified Individual)

1. Name your Segment
2. Configure your publishing settings
3. Drag attributes onto the canvas and define your criteria
4. Save and publish

Understanding Direct Attributes vs. Related Attributes

This is one of the biggest mindset shifts for Account Engagement users.

When building criteria in the Visual Builder, you’ll typically see two types of attributes:

Direct Attributes

Direct Attributes live directly on the object you’re segmenting against.

For example, if you’re building a segment on the Unified Individual object, direct attributes might include:

• First Name
• Last Name
• Country
• State
• Preferred Language

Think of these as fields that belong directly to the person.

Example: Country = United States

This is a simple, direct attribute filter.

Related Attributes

Related Attributes come from connected objects that are related to the object you’re segmenting on.

Examples include:

• Email engagement activity
• Opportunities
• Campaign Membership
• Website activity
• Orders
• Cases

Think of these as records associated with the person rather than fields that live directly on the person.

Example: Opened an email in the last 30 days

The email open isn’t stored directly on the Unified Individual record. It’s stored on a related engagement object.

When Should You Use Each?

A simple rule:

• Use Direct Attributes when filtering on profile or demographic information.
• Use Related Attributes when filtering on behavior, engagement, transactions, or relationships.

If you’re asking “Who is this person?” you’re usually looking at Direct Attributes.

If you’re asking “What has this person done?” you’re usually looking at Related Attributes.

Understanding that distinction makes segment building much easier and helps explain why some criteria appear in different areas of the builder.

Option 2: Use Quick Filters 

Need a common audience fast? Quick Filters offer predefined criteria for standard scenarios like:

• New Contacts created today
• New Leads created today
• Recent Campaign Members
• Contacts related to a won Opportunity

Access Quick Filters by navigating to Campaign while in the Marketing Cloud Next app. Open a campaign and select Select Segment. It’s a great starting point if you’re brand new to the platform.

Option 3: Use Einstein to Build a Draft 

Not sure where to begin? Einstein Segment Creation lets you describe the audience you want in plain language:

Show me subscribers who opened an email in the last 30 days, visited our pricing page, and are subscribed to product updates. 

Einstein generates a draft segment you can review, refine, and publish. Think of it as a shortcut to a first draft and always validate the output before going live.

Option 4: Use a Dynamic Segment

If you find yourself creating the same types of audiences repeatedly, Dynamic Builders can help streamline the process. Instead of starting from scratch each time, Dynamic Builders let you create reusable audience templates with configurable criteria. Marketers can then generate new segments from those templates by simply selecting or updating a few values, helping ensure consistency across campaigns while reducing manual effort. They’re especially useful for organizations with standardized audience definitions or recurring segmentation needs, allowing teams to scale segmentation without rebuilding the same logic over and over.

Which option should you choose? If you’re just getting started, use Quick Filters for common audiences or the Visual Builder for custom logic. Einstein Segment Creation is a great way to generate a first draft from natural language, while Dynamic Builders are best when your organization wants to standardize and reuse the same audience patterns across multiple campaigns.

Tips, Gotchas, and Things I Tell Every Client

Use the IN Operator Instead of Stacking OR Conditions

If your CRM has multiple versions of the same value, the IN operator saves you a lot of time. Instead of building three separate OR conditions, write: 

Country IN (USA, US, United States)

It supports up to 100 values. Clean, readable, and much easier to maintain.

Understand Measurements, Operators, and Values

When working with behavioral data, Data 360 often asks you to combine three pieces:

• Measurement
• Operator
• Value

For example: Email Opens → Count → At Least → 1

This translates to: “The person has opened at least one email.”

Another example: Email Clicks → Count → Greater Than → 5

This translates to: “The person has clicked more than five emails.”

Think of it like a sentence: Measurement + Operator + Value = Audience Rule

Examples:

• Count At Least 1
• Count Equals 0
• Sum Greater Than 1000
• Count Between 5 and 10

If a segment returns unexpected results, this combination is often the first place I investigate. The measurement may be correct, but the operator or value may not align with the business requirement.

Use Include and Exclude Intentionally

One of the most common mistakes I see is placing all data requirements into the “Include” section. Instead, think of Include as those who belong and Exclude as those who don’t belong. Separating those concepts creates cleaner segments and makes troubleshooting much easier.

Include Criteria: Country IN (USA, US, United States)

Exclude Criteria: Emailed in the last 3 days

Use EQUALS When Your Data Is Clean

When a field is standardized, and you only need one exact match, EQUALS is the right call. Country EQUALS USA will only return records where the value is exactly “USA.” No flexibility, but that’s the point.

Build Frequency and Recency Into Your Logic

This is where Data 360 starts to feel genuinely different from Account Engagement. You can filter by:

• Has been emailed X times in the last Y days is great for suppression. If someone has received 3 emails in the last 7 days, you probably don’t want to send them a fourth.
• Has not engaged in X days is your re-engagement and deliverability workhorse. Use it to identify lapsed subscribers before they become a problem.
• Subscribed to [Preference] will build audiences based on what contacts have explicitly opted into. Increasingly important for compliance and deliverability.

Always Preview Before You Publish

Segment Preview lets you check audience size, sample records, and whether your include/exclude logic is working as intended. A few minutes here can save hours of troubleshooting later.

Account for Processing Time

Data 360 isn’t always instantaneous. Initial data ingestion can take days, depending on volume. Segment calculations take time and Dynamic Lists connected to a Data 360 Segment can take up to three hours to populate the first time. If nothing shows up immediately, give it time before assuming something is broken.

Not All Account Engagement Activity Is Automatically Available

A common misconception: not every historical activity flows into Data 360 by default. What’s available depends on your connector configuration and the Filter By Date you set when connecting. Before building complex engagement-based segments, confirm what data is actually being ingested.

Data 360 Doesn’t Honor CRM Visibility Rules

This one surprises many Salesforce Admins. Users can segment records in Data 360 that they can’t see in the CRM. If access control matters for your org, address it before rolling out segmentation broadly. The most reliable controls are user permissions and Business Units.

From Segment to Activation

One of the biggest misconceptions I encounter: adopting Data 360 means abandoning Account Engagement. It doesn’t. One of my favorite use cases is building sophisticated audiences in Data 360 and activating them directly through Account Engagement via the Data 360 Connector. To connect a Data 360 Segment to Account Engagement:

1. Navigate to Account Engagement → Segmentation → Lists
2. Create a Dynamic List
3. Select Data Cloud Segment as the Dynamic List Type
4. Choose your published segment

The first sync takes up to three hours. After that, membership updates automatically whenever the segment refreshes. Once connected, the Dynamic List works anywhere in Account Engagement, including Engagement Studio, Automation Rules, List Emails, Completion Actions, and Reporting. Data 360 identifies the audience. Account Engagement engages it. That’s where the value compounds.

Three Segments to Build First

Not sure where to start? These three are worth building in almost every org.

Recently Engaged Contacts: people actively interacting with your brand. Use for webinar invitations, product launches, or newsletters.

• Opened an email in the last 30 days, OR
• Clicked an email in the last 30 days, OR
• Visited your website in the last 30 days

Inactive Subscribers (90+ Days): Subscribers who’ve gone quiet. Use for re-engagement campaigns, deliverability cleanup, or preference center outreach. This audience frequently surfaces new pipeline.

• Opted in, AND
• No opens in 90 days, OR
• No clicks in 90 days

Preference Center Subscribers: Contacts who’ve told you exactly what they want. Use for targeted newsletters, product announcements, or event promotions.

• Opt in to Product Updates

Data 360 segmentation isn’t replacing the skills you’ve built in Account Engagement; it’s extending them. You’re still defining criteria, building audiences, and activating campaigns. The difference is you now have richer data and more ways to use it. Start simple. Build a Quick Filter segment, get comfortable with the interface, then move into the Visual Builder. Before long, you’ll stop asking how to recreate Dynamic Lists and start asking what was possible all along.