The Big 3 Diagrams: System Landscape, Data Model, Role Hierarchy

These three diagrams form the backbone of every CTA presentation. They address the highest-weighted scoring domains and are the artifacts judges will spend the most time probing during Q&A.

The Big 3 Are a Subset of the Core 7

CTA coaching sources (FlowRepublic, Apex Hours, TrailblazePrep, Cloud Johann) converge on 7 core diagrams that every CTA presentation should include — the Big 3 (System Landscape, Data Model, Role Hierarchy) plus 4 additional core diagrams: Integration Architecture, Security/Identity Model, Migration Strategy, and Deployment/Environment. The Big 3 are your highest-priority artifacts because they address the heaviest-weighted scoring domains, but a complete presentation requires all 7. The other 4 are covered in Supporting Artifacts.

1. System Landscape Diagram

What it is: A high-level view of all systems in the solution and how they relate to each other.

Why it matters: This is your opening move. It establishes the entire scope of your solution at a glance — Salesforce orgs, external systems (ERP, marketing platforms, data warehouses), middleware, portals, mobile apps, and the connections between them.

What to include:

Element	Details
All Salesforce products	Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, etc.
External systems	ERP, data warehouse, marketing tools, document management, legacy systems
Middleware / integration layer	MuleSoft, Heroku, custom APIs, ESB
User-facing channels	Web portals, mobile apps, communities, call center
Integration interfaces	High-level arrows showing data flow direction and integration type (API, ETL, events)
System ownership	Which team or department owns each system

Diagram best practices:

Position Salesforce at the center (it is the solution platform)
Use color coding: Salesforce products in blue, external systems in gray, integration layer in orange, user channels in green
Label every connection with the integration type (REST API, SOAP, ETL, Platform Events, Change Data Capture)
Label data flow direction on every arrow — judges should see which way data moves without you explaining it
Always show an explicit integration/middleware layer (MuleSoft, ESB, or equivalent) between Salesforce and external systems — do NOT draw direct point-to-point arrows without middleware
Include a mandatory legend explaining your color scheme, icons, and system status (see Legend Requirements below)
Keep it to a single page — if it needs more detail, create a Level 2 integration diagram

Integration layer is non-negotiable

Approximately 95% of CTA scenarios require an explicit integration/middleware layer (MuleSoft, ESB, or API gateway) in the System Landscape. Drawing direct arrows from Salesforce to an ERP or data warehouse without showing middleware is a red flag for judges. Even if the scenario does not explicitly mention middleware, you should include it — real enterprise architectures always have an integration layer. The only exception is a trivially simple scenario with a single point-to-point integration, and even then, showing middleware demonstrates enterprise thinking.

Maps to domains: System Architecture (D1), Integration (D5), Solution Architecture (D4)

Reference structure — a typical system landscape follows this pattern:

flowchart TB
    subgraph Users["User Channels"]
        WEB["Web Portal"]
        MOB["Mobile App"]
        INT["Internal Users"]
    end

    subgraph SF["Salesforce Platform"]
        SC["Sales Cloud"]
        SVC["Service Cloud"]
        EC["Experience Cloud"]
    end

    subgraph EXT["External Systems"]
        ERP["ERP System"]
        MKT["Marketing Platform"]
        DW["Data Warehouse"]
    end

    MW["Middleware\n(MuleSoft / Heroku)"]

    INT -->|"UI"| SC
    INT -->|"UI"| SVC
    WEB -->|"Portal"| EC
    MOB -->|"API"| EC
    SF <-->|"REST / Events"| MW
    MW <-->|"SOAP / ETL"| EXT

Legend Requirements

Every System Landscape diagram must include a legend. The legend is not optional — it is a required component of the Salesforce diagramming framework. A missing legend is listed as a characteristic of failing artifacts.

What your legend must show:

Legend Element	Purpose
Color coding	What each color represents (blue = Salesforce, gray = external, orange = integration, green = user channels)
System status	Which systems are new (being implemented), which are retiring (being decommissioned), and which are keeping (staying as-is). Use distinct colors or border styles for each status
Line styles	What solid vs dashed lines mean (e.g., solid = active integration, dashed = planned/future)
Arrow direction	What arrow directions represent (data flow direction, not just “connected to”)
Icons	If you use icons for system types (cloud, on-prem, mobile), explain them in the legend

System status color coding example:

Status	Suggested Style	Meaning
New (implementing)	Green border or green highlight	System being built or deployed as part of this solution
Retiring (decommissioning)	Red border or strikethrough	Legacy system being replaced — show what replaces it
Keeping (as-is)	Standard gray fill	Existing system that remains unchanged
Salesforce (platform)	Blue fill	Salesforce products at the center of the solution
Integration layer	Orange fill	MuleSoft, ESB, API gateway

Legend placement

Place the legend in the bottom-right or bottom-left corner of the diagram. It should be visible but not dominate the diagram. In Lucidchart, use a small grouped box with colored squares and labels. The Salesforce diagramming framework recommends including the legend in the diagram header area.

2. Data Model / Entity Relationship Diagram (ERD)

What it is: The logical data model showing standard objects, custom objects, and their relationships.

Why it matters: Data is one of the most heavily scrutinized domains. Judges will probe your object choices, relationship types, cardinality, ownership model, and how the data model supports the sharing architecture.

What to include:

Element	Details
Standard objects used	Account, Contact, Opportunity, Case, Lead, etc.
Custom objects	With clear naming and purpose
Relationships	Master-Detail vs. Lookup, with cardinality (1:1, 1:N, N:N via junction)
Record ownership	Who owns records of each object type (critical for sharing model)
OWD settings	Org-Wide Default access level for each key object (Private, Public Read Only, Public Read/Write)
Key fields	Only fields that drive architecture decisions (external IDs, formula fields, roll-up summaries)
Data volumes	Approximate record counts per object (especially for LDV considerations)
External objects	If using Salesforce Connect / External Objects

Diagram best practices:

Use standard ERD notation (crow’s foot for cardinality)
Group related objects visually (Sales objects together, Service objects together)
Annotate OWD settings directly on the diagram or in a companion table
Highlight junction objects for many-to-many relationships
Call out LDV objects (those exceeding 1M+ records) with a visual marker
Show record ownership arrows or annotations for objects critical to the sharing model

Maps to domains: Data (D3), Security (D2), Solution Architecture (D4)

Reference ERD notation — show relationship types, ownership, and LDV markers:

erDiagram
    Account ||--o{ Contact : "has (MD)"
    Account ||--o{ Opportunity : "has (Lookup)"
    Account ||--o{ Case : "has (Lookup)"
    Opportunity ||--o{ OpportunityLineItem : "has (MD)"
    Product2 ||--o{ OpportunityLineItem : "linked (Lookup)"
    Contact ||--o{ Case : "reported by (Lookup)"

    Account {
        string Name
        string OWD "Private"
        string Volume "2M records - LDV"
        string Owner "Sales Rep"
    }
    Opportunity {
        string OWD "Private"
        string Owner "Opp Owner"
    }
    Case {
        string OWD "Private"
        string Volume "5M records - LDV"
        string Owner "Queue then Agent"
    }

What it is: The organizational hierarchy that drives record-level data visibility, combined with the sharing architecture.

Why it matters: Many candidates fail the board due to gaps in their sharing model. This diagram is where you demonstrate your understanding of Salesforce’s multi-layered security model.

What to include:

Element	Details
Role hierarchy tree	All roles from CEO down to portal users
OWD summary	Per-object Org-Wide Defaults
Sharing rules	Criteria-based and ownership-based sharing rules
Sharing mechanisms	Apex Managed Sharing, Manual Sharing, Team Sharing
Territory Management	If applicable to the scenario
Permission Sets	Key permission sets and permission set groups
Portal/Community roles	How external users fit into the hierarchy
Profile-to-role mapping	Which profiles are assigned to which roles

Diagram best practices:

Draw the role hierarchy as a tree structure (top-down)
Annotate each level with example users or user counts
Use a companion table (in Google Sheets) to document OWD per object if the diagram gets too busy
Show how data flows “up” through the hierarchy (role-based sharing opens access upward)
Clearly mark where external users sit in the hierarchy
Distinguish between internal and external sharing rules

Maps to domains: Security (D2), Data (D3)

Reference role hierarchy structure — show the tree with portal users and annotations:

flowchart TD
    CEO["CEO / Executive"]
    VP["VP Sales / VP Service"]
    MGR["Regional Manager"]
    REP["Sales Rep / Agent"]
    PORTAL["Portal Role"]

    CEO --> VP
    VP --> MGR
    MGR --> REP
    REP -.->|"separate branch"| PORTAL

    CEO ---|"sees all records\n(role hierarchy)"| VP
    PORTAL ---|"Community license\nOWD: Private\nSharing Rules: criteria-based"| REP

Role hierarchy diagram tips

Annotate each level with user counts and sharing implications. Show where external/portal users sit — they are always in a separate branch below internal users. Mark OWD settings and any territory management overlays directly on the diagram.

The Big 3 Diagrams: System Landscape, Data Model, Role Hierarchy

1. System Landscape Diagram

Legend Requirements

2. Data Model / Entity Relationship Diagram (ERD)

3. Role Hierarchy & Sharing Model Diagram