Generate a Beautiful Dataverse ERD in 5 Minutes

Open the maker portal. Click into a table. Write down the columns. Click into the next table. Write down the columns. Trace the lookup relationships by opening each column definition. Paste everything into Visio. Draw boxes. Draw arrows. Spend 20 minutes routing the arrows so they don’t cross. Realize you missed a table. Start over.

That’s how most Dataverse ERDs get created. And that’s why most Dataverse projects don’t have one.

Why Are Most Dataverse ERDs Ugly?

I’ve seen hundreds of Dataverse projects. Maybe 10% had a readable ERD. The rest had one of three problems:

Problem 1: The schema dump. Someone exports every table and every column. The result is a wall of boxes connected by a spider web of crossing lines. You can’t read it without a magnifying glass. More information doesn’t mean more useful.

Problem 2: The PowerPoint special. Someone draws boxes in PowerPoint with straight-line arrows. No column details. No relationship cardinality. No color coding. It looks professional from across the room and tells you nothing up close.

Problem 3: No ERD at all. The most common outcome. The project ships without data model documentation because nobody had time to draw it. Six months later, a new developer joins and spends their first two weeks reverse-engineering the schema from the solution XML.

What Makes a Dataverse ERD Beautiful?

A beautiful ERD isn’t decoration. It’s communication. Here’s what separates a useful ERD from a forgettable one:

The 7 plus or minus 2 rule applies to ERDs just like it applies to UI design. Show 5-9 tables per diagram. If your schema has 30 tables, create 4 domain-specific ERDs instead of one massive one that nobody can read.

The Cascade Dynamics Schema

Here’s a real example. Cascade Dynamics has 6 core Dataverse tables across 3 domains:

Domain	Tables	Color
Clinical	csd_patient, csd_clinicalcase	Blue (#e8f0fe)
Provider	csd_clinician	Green (#e6f4ea)
Scheduling	csd_appointment	Amber (#fef7e0)
Documents	csd_document	Purple (#f3e8fd)
Compliance	csd_auditlog	Gray (#f8f9fa)

Each table shows the columns that matter: primary keys, foreign keys, and the business-relevant fields. System columns like createdby, modifiedon, statecode are deliberately excluded.

The ai_summary column on csd_document is a deliberate detail. When someone reads this ERD, they immediately know that AI processing is part of the data pipeline. That kind of signal is what separates a documentation artifact from a communication tool.

How I Generate This in 5 Minutes

The function that produces this ERD is 25 lines of TypeScript:

function generateCascadeERD() {
  // Tables with key columns
  const patient = addEntityBox(30, 30, 180, 'csd_patient',
    ['patientid (PK)', 'fullname', 'dateofbirth',
     'ssn_last4', 'facilityid (FK)', 'status'], blue);

  const clinCase = addEntityBox(280, 30, 180, 'csd_clinicalcase',
    ['caseid (PK)', 'patientid (FK)', 'clinicianid (FK)',
     'casetype', 'status', 'priority', 'createdon'], blue);

  const clinician = addEntityBox(530, 30, 180, 'csd_clinician',
    ['clinicianid (PK)', 'fullname', 'specialty',
     'facilityid (FK)', 'npi_number', 'active'], green);

  // Relationships
  addEdge(patient, clinCase, '1:N');
  addEdge(clinician, clinCase, '1:N');
  addEdge(patient, appointment, '1:N');
  addEdge(clinCase, document, '1:N');
}

The addEntityBox helper does the heavy lifting. It calculates the box height from the column count, applies the domain color, formats the table name as bold with columns below, and returns an ID for edge connections.

The addEdge helper creates orthogonal edges with explicit entry/exit points so arrows don’t tangle. Cardinality labels sit on the edge.

Run the script: a .drawio file appears. Export to SVG. Done.

The 5-Minute Workflow

Here’s the actual sequence:

1. List your tables - which Dataverse tables matter for this diagram? Pick 5-9. (30 seconds)
2. Assign colors by domain - pick from the approved palette. (15 seconds)
3. Choose key columns - PKs, FKs, and 3-5 business fields per table. Skip system columns. (2 minutes)
4. Write the function - position tables, add edges with cardinality. (2 minutes)
5. Run and verify - generate the .drawio, export to SVG, visual check. (30 seconds)

The first time takes closer to 10 minutes because you’re learning the helpers. After that, 5 minutes is generous.

Before and After: Manual vs Generated

The update cost is the killer difference. When you add a column to csd_clinicalcase, you add one string to the array and regenerate. The diagram stays current because updating it is trivial.

Adapting This to Your Schema

The pattern works for any Dataverse schema. Here’s how to adapt it:

Step 1: Replace the table names and columns with your schema. Use your publisher prefix instead of csd_.

Step 2: Assign colors by domain. Use the approved palette (blue, green, amber, purple, gray). Pick one color per logical domain.

Step 3: Position tables to minimize edge crossings. Put related tables adjacent to each other. FK relationships should flow left-to-right or top-to-bottom.

Step 4: Add edges with cardinality. Every lookup column is a 1:N relationship. N:N relationships get dashed edges.

For the full process of exporting your Dataverse schema and feeding it to the ERD generator, see XrmToolBox Schema Export to ERD with Claude. That article covers the extraction side. This article covers making the output beautiful.

The Mermaid Alternative

Not every ERD needs to be a Draw.io SVG. For quick documentation in markdown files, README, or pull request descriptions, Mermaid renders directly in GitHub:

erDiagram
    csd_patient {
        guid patientid PK
        string fullname
        date dateofbirth
        string ssn_last4
        guid facilityid FK
        int status
    }

    csd_clinicalcase {
        guid caseid PK
        guid patientid FK
        guid clinicianid FK
        string casetype
        int status
        int priority
        datetime createdon
    }

    csd_clinician {
        guid clinicianid PK
        string fullname
        string specialty
        guid facilityid FK
        string npi_number
        boolean active
    }

    csd_appointment {
        guid appointmentid PK
        guid patientid FK
        guid clinicianid FK
        datetime scheduleddate
        string type
        int status
    }

    csd_document {
        guid documentid PK
        guid caseid FK
        string filename
        string documenttype
        string ai_summary
        datetime uploadedon
    }

    csd_auditlog {
        guid auditid PK
        string entityname
        guid recordid
        string action
        guid changedby
        datetime changedon
    }

    csd_patient ||--o{ csd_clinicalcase : "has cases"
    csd_clinician ||--o{ csd_clinicalcase : "assigned to"
    csd_patient ||--o{ csd_appointment : "has appointments"
    csd_clinician ||--o{ csd_appointment : "sees patients"
    csd_clinicalcase ||--o{ csd_document : "has documents"
    csd_clinicalcase ||--o{ csd_auditlog : "triggers audit"

The Mermaid version gives you proper crow’s-foot notation for free. GitHub, GitLab, Azure DevOps wikis, and Notion all render it natively. No SVG files, no export pipeline. Just paste it in a markdown file and it renders.

When to use which:

• Draw.io SVG: Published articles, presentations, formal documentation. Color-coded, icon-rich, pixel-perfect.
• Mermaid: README files, PR descriptions, internal wikis, quick reference. Free, zero-maintenance, renders anywhere.

My Honest Take

Every Dataverse project should have an ERD committed to git by the end of week 1. Not a 50-table monster - a focused, 5-9 table diagram for each domain area.

The ERD is the first diagram anyone should create. It anchors every other architecture decision. Your integration map shows what connects to what. Your state machine shows how records transition. Your data flow shows where data moves. But the ERD shows what the data actually IS.

If your ERD is ugly, nobody reads it. If nobody reads it, nobody understands the schema. If nobody understands the schema, the next developer spends two weeks reverse-engineering what should have taken 5 minutes to document.

Make it beautiful. Make it generated. Make it version-controlled. The schema is too important for a PowerPoint drawing that nobody updates.

---

For the full enterprise architecture diagramming approach (20 diagrams across 5 categories), see 20 Architecture Diagrams in 20 Minutes. For the complete diagramming pipeline with Draw.io MCP, see Architecture Diagrams with Draw.io MCP and Claude.