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:UserscategDataCloud 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.

Original article: Get your Data Model Out of Your Head (and into a Diagram) using Salesforce CLI & Diagramforce

©2026 The Spot. All Rights Reserved.

The post Get your Data Model Out of Your Head (and into a Diagram) using Salesforce CLI & Diagramforce appeared first on The Spot.