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 probe most heavily 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 the opening move. It establishes the entire scope of the 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, cloud services, 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 verbal explanation
• 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 the color scheme, icons, and system status (see Legend Requirements below)
• Keep it to a single page. If more detail is needed, create a Level 2 integration diagram

Integration layer is non-negotiable

Roughly 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 middleware is a red flag for judges. Even if the scenario text does not mention middleware, 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:

Figure 1. Reference structure for the System Landscape diagram. The middleware layer between the Salesforce platform and external systems is mandatory. Drawing direct point-to-point arrows without it is a known failure pattern judges flag immediately.

Legend Requirements

Every System Landscape diagram must include a legend. It is not optional. It is a required component of the Salesforce diagramming framework, and 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 layout. In Lucidchart, a small grouped box with colored squares and labels works well. The Salesforce diagramming framework recommends placing the legend in the 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 probe 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:

Figure 2. Reference ERD for the Data Model artifact, annotated with OWD settings, record ownership, and LDV volume markers. Judges probe relationship type choices (Master-Detail vs Lookup) and ownership annotations because they directly determine sharing model behavior.

3. Role Hierarchy & Sharing Model Diagram

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 on gaps in their sharing model. This diagram demonstrates 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:

Figure 3. Reference role hierarchy structure showing internal roles and the portal branch as a separate tree. The sharing annotations on each level are what judges probe most: OWD choice, sharing rule type, and how external users gain access without inheriting internal record visibility.

Role hierarchy diagram tips

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

Related Topics

• Supporting Artifacts: Tier 2 and Tier 3 artifacts that complement the Big 3
• Artifact Process & Quality Standards: time allocation, tools, and mandatory diagram standards
• Data Modeling: source content for the ERD artifact including relationship types and ERD patterns
• Sharing Model: source content for the Role Hierarchy diagram including OWD, sharing rules, and access layers
• Integration Patterns: System Landscape requires integration pattern and middleware knowledge
• Org Strategy: System Landscape centers on org strategy and the platform ecosystem