Big 3 Artifacts Quick-Ref

The three diagrams that form the backbone of every CTA presentation. Judges spend the most Q&A time probing these. Get them wrong and you fail; get them right and you have a strong foundation for the remaining artifacts.

1. System Landscape Diagram

Purpose: High-level view of all systems and how they connect. Your opening move — establishes the entire solution scope at a glance.

What to Include

Element	Details
Salesforce products	Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, etc.
External systems	ERP, data warehouse, marketing tools, DMS, legacy systems
Middleware	MuleSoft, Heroku, custom APIs, ESB
User channels	Web portals, mobile apps (type: native/hybrid/HTML5), communities
Integration arrows	Direction + type (REST, SOAP, ETL, Platform Events, CDC)
System ownership	Which team/department owns each system
Mobile apps	Include mobile device type and app approach (Salesforce Mobile, custom)

Layout Rules

flowchart TB
    subgraph Users["User Channels"]
        WEB[Web Portal]
        MOB[Mobile App]
        INT[Internal Users]
    end
    subgraph SF["Salesforce Platform (CENTER)"]
        SC[Sales Cloud]
        SVC[Service Cloud]
        EC[Experience Cloud]
    end
    subgraph EXT["External Systems"]
        ERP[ERP System]
        DW[Data Warehouse]
        MKT[Marketing Platform]
    end
    subgraph MW["Integration Layer"]
        MULE[MuleSoft]
    end

    Users --> SF
    SF <-->|REST API| MW
    MW <-->|SOAP/ETL| EXT

    style SF fill:#1B96FF,color:#fff
    style EXT fill:#706E6B,color:#fff
    style MW fill:#FE9339,color:#fff
    style Users fill:#2E844A,color:#fff

Rule	Why
Salesforce at center	It is the solution platform — everything radiates from it
Color code consistently	Blue = Salesforce, Gray = external, Orange = integration, Green = channels
Label every arrow	Integration type + direction (no unlabeled connections)
Single page only	If it needs more detail, create a Level 2 integration diagram separately
Include a legend	Explain colors, icons, line styles

Mandatory Checklist (verify before presenting)

Check	Pass?
Integration layer (MuleSoft/ESB) shown between Salesforce and all external systems?
Legend included with color coding and system status (new/retiring/keeping)?
Every arrow labeled with direction, integration type, and protocol?
All systems from the scenario accounted for?
Salesforce positioned at center?

Two non-negotiable items

Integration layer and legend are mandatory on every System Landscape. ~95% of CTA scenarios require an explicit middleware layer. A diagram without a legend or with direct point-to-point arrows (no middleware) is a failing artifact pattern.

Common Mistakes

System Landscape gotchas

Missing integration layer — direct arrows from Salesforce to ERP/DW with no MuleSoft/ESB shown (the most common structural mistake)
Missing legend — no color key, no system status (new/retiring/keeping), no line style explanation
Missing systems — forgetting a system mentioned in the scenario (read the scenario twice)
No integration types — arrows without labels (REST? SOAP? ETL? Platform Events?)
Missing mobile — the scenario mentions mobile users but you forgot the mobile channel
No ownership — judges ask “who owns this system?” and you have no answer
Too detailed — this is Level 1. Do NOT show individual objects or Apex classes here

Judge Q&A Targets

Question Pattern	How to Prepare
”Why this mix of on-platform vs off-platform?”	Know platform limits that justify external systems
”What if this external system goes down?”	Have a fallback / circuit-breaker answer ready
”Why not consolidate these two systems?”	Articulate the cost/capability trade-off

2. Data Model / ERD

Purpose: Logical data model showing standard objects, custom objects, relationships, and cardinality. One of the most heavily scrutinized artifacts.

What to Include

Element	Details
Standard objects	Account, Contact, Opportunity, Case, Lead, etc.
Custom objects	Clear naming + stated 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
OWD settings	Private, Public Read Only, or Public Read/Write per key object
Key fields	External IDs, formula fields, roll-up summaries (only architecture-driving fields)
Data volumes	Approximate record counts (flag LDV objects with 1M+ records)
External objects	If using Salesforce Connect

Notation Reference

erDiagram
    ACCOUNT ||--o{ CONTACT : "has many"
    ACCOUNT ||--o{ OPPORTUNITY : "has many"
    OPPORTUNITY ||--|{ OPPORTUNITY_LINE_ITEM : "master-detail"
    OPPORTUNITY }o--o{ PRODUCT : "junction: PricebookEntry"
    ACCOUNT ||--o{ CASE : "has many"

    ACCOUNT {
        string Name
        string External_ID__c
        string OWD "Private"
        string Volume "2M records"
    }
    CONTACT {
        string Name
        string OWD "Controlled by Parent"
    }

Layout Rules

Rule	Why
Crow’s foot notation	Standard ERD cardinality that judges expect
Group related objects	Sales objects together, Service objects together
Annotate OWD on diagram	Or in a companion Google Sheets table if too busy
Highlight junction objects	Many-to-many relationships need explicit junction objects
Flag LDV objects visually	Star/icon marker on objects exceeding 1M records
Show ownership arrows	Critical for judges to evaluate sharing model

Master-Detail vs Lookup Decision

Factor	Master-Detail	Lookup
Cascade delete	Yes — child deleted with parent	No — child orphaned
Sharing inheritance	Child inherits parent sharing	Independent sharing
Roll-up summaries	Supported	Not supported (use Flow/Apex)
Required relationship	Always required	Can be optional
Reparenting	Not by default (can enable)	Always allowed
Lock contention risk	Higher on high-traffic parents	Lower
CTA rule of thumb	Use when child cannot exist without parent	Use for loose associations

Common Mistakes

Data Model gotchas

No cardinality — showing relationships without 1:N or M:N notation
Missing OWD — the ERD exists but does not show org-wide defaults
Ignoring LDV — objects with millions of records shown with no volume annotation
Over-using Master-Detail — creates lock contention on high-traffic parent objects
No external IDs — migration and integration depend on these; judges will ask
Wrong level of detail — showing every field vs showing only architecture-driving fields

Judge Q&A Targets

Question Pattern	How to Prepare
”Why Master-Detail vs Lookup here?”	Know the 6 comparison factors above
”How do you handle 10M+ records on this object?”	Indexing, skinny tables, archiving, Big Objects
”Walk me through the migration load order”	Parent objects first, junction objects last
”What is your query optimization for LDV?”	Selective queries, custom indexes, async processing

Purpose: The organizational hierarchy driving record-level visibility, combined with the complete sharing architecture. The #1 failure domain.

What to Include

Element	Details
Role hierarchy tree	CEO down to portal users, as a top-down tree
OWD summary	Per-object defaults (Private, Public Read Only, Public Read/Write)
Sharing rules	Criteria-based and ownership-based, with which objects
Sharing mechanisms	Apex Managed Sharing, Manual Sharing, Team Sharing
Territory Management	If scenario involves geographic or named-account territories
Permission Sets	Key PSGs for feature access
Portal/Community roles	Where external users sit in the hierarchy
Profile-to-role mapping	Which profiles are assigned to which roles

flowchart BT
    OWD["1. Org-Wide Defaults (OWD)\nMost restrictive baseline"]
    RH["2. Role Hierarchy\nOpens access UP the tree"]
    SR["3. Sharing Rules\nOwnership-based + Criteria-based"]
    TS["4. Teams / Territory\nManual + managed sharing"]
    AMS["5. Apex Managed Sharing\nProgrammatic sharing"]
    MS["6. Manual Sharing\nUser grants one-off access"]

    OWD --> RH --> SR --> TS --> AMS --> MS

    style OWD fill:#d4504c,color:#fff
    style RH fill:#FE9339,color:#fff
    style SR fill:#1B96FF,color:#fff

The golden rule

Start restrictive (Private OWD), then open access with sharing rules. Never start with Public Read/Write and try to restrict down — Salesforce does not support “closing” access below OWD.

OWD Decision Quick-Ref

If…	Set OWD to…	Then open with…
Most users should NOT see most records	Private	Sharing rules, role hierarchy, teams
Most users need to read but not edit	Public Read Only	Sharing rules for edit access
Everyone can see and edit everything	Public Read/Write	Nothing (already fully open)
Child object follows parent visibility	Controlled by Parent	Parent OWD + sharing rules

Common Mistakes

Sharing model failures — the #1 killer

No OWD justification — saying “Private” without explaining why
Forgetting portal users — 50K community users in Private OWD = sharing explosion
Flat hierarchy — too few roles, not reflecting actual data access needs
Org-chart copy — role hierarchy should reflect data access, NOT reporting structure
Ignoring scale — sharing rules that work for 100 users break at 50,000 users
No sharing rules documented — judges expect you to name specific rules, not just say “sharing rules”
Missing Apex Managed Sharing — when standard sharing mechanisms are insufficient

Judge Q&A Targets

Question Pattern	How to Prepare
”Walk me through how user X sees record Y”	Trace the path: OWD -> role -> sharing rule -> teams
”What if you have 50K portal users?”	Sharing sets, high-volume portal users, sharing group limits
”Why Private instead of Public Read Only?”	Business justification for restriction level
”What happens to sharing when a user changes roles?”	Sharing recalculation, implicit vs explicit shares
”How does Territory Management fit?”	When geography-based or named-account access is needed

Big 3 Interaction Map

These three diagrams are deeply interconnected. Judges will test whether your artifacts are consistent with each other.

flowchart LR
    SL["System Landscape\n(what systems exist)"]
    DM["Data Model\n(what data lives where)"]
    RH["Role Hierarchy\n(who sees what data)"]

    SL -->|"systems determine\ndata sources"| DM
    DM -->|"object ownership\ndrives sharing"| RH
    RH -->|"access patterns\nshape system design"| SL

    style SL fill:#1B96FF,color:#fff
    style DM fill:#2E844A,color:#fff
    style RH fill:#d4504c,color:#fff

Cross-reference Check	What to Verify
System Landscape <-> Data Model	Every external system in the landscape has data that flows to/from objects in the ERD
Data Model <-> Role Hierarchy	Every object with Private OWD has a sharing mechanism defined in the role hierarchy artifact
Role Hierarchy <-> System Landscape	Portal users in the role hierarchy connect to the Experience Cloud portal in the landscape

Big 3 Artifacts Quick-Ref

1. System Landscape Diagram

What to Include

Layout Rules

Mandatory Checklist (verify before presenting)

Common Mistakes

Judge Q&A Targets

2. Data Model / ERD

What to Include

Notation Reference

Layout Rules

Master-Detail vs Lookup Decision

Common Mistakes

Judge Q&A Targets

3. Role Hierarchy + Sharing Model

What to Include

Sharing Model Layers (Bottom-Up)

OWD Decision Quick-Ref

Common Mistakes

Judge Q&A Targets

Big 3 Interaction Map

Sources