Big 3 Artifacts Quick-Ref

These three diagrams form the backbone of every CTA presentation. Judges spend the most Q&A time probing them. Get them wrong and you fail. Get them right and the remaining artifacts build on a solid base.

1. System Landscape Diagram

Purpose: High-level view of all systems and how they connect. This is your opening move, establishing the full 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, cloud services, 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

Figure 1. Salesforce belongs at the center of the system landscape and every other system radiates from it. The integration layer must be explicit between Salesforce and all external systems; direct point-to-point arrows without a middleware layer shown is one of the most common structural mistakes on CTA presentations.

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. Judges scrutinize this heavily.

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

Figure 2. Annotating OWD and record volume directly on the ERD gives judges the security and LDV context without requiring a separate artifact. An Account at 2M records with Private OWD immediately signals that sharing recalculation performance and indexing strategy must be addressed in the solution.

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

---

3. Role Hierarchy + Sharing Model

Purpose: The organizational hierarchy driving record-level visibility, combined with the full sharing architecture. This is 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

Sharing Model Layers (Bottom-Up)

Figure 3. The bottom-up orientation reflects how sharing builds: OWD is the floor that every user starts from, and each layer above can only expand that floor, never lower it. Judges use this diagram to probe whether you can trace exactly how a specific user gains access to a specific record.

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 tightly connected. Judges will test whether your artifacts stay consistent with each other.

Figure 4. The Big 3 artifacts form a closed loop of dependencies: inconsistencies between them (a portal user in the role hierarchy with no Experience Cloud site in the landscape, or a Private-OWD object in the ERD with no sharing mechanism in the role hierarchy) are exactly what judges probe in cross-artifact questions.

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

---

Sources

• Salesforce Diagramming Framework - architect.salesforce.com
• Salesforce Role Hierarchy Reference - architect.salesforce.com
• Salesforce Data Model Notation - developer.salesforce.com
• CTA Diagramming Framework - FlowRepublic
• CTA Certification Guide & Tips - Salesforce Ben
• Brief Insights from a CTA Board Judge - Dinesh Yadav
• Deep Dive into JourneyToCTA - Apex Hours