Supporting Artifacts Quick-Ref

Tier 2 artifacts round out the CTA presentation. Each covers a specific scoring domain. Judges probe these less deeply than the Big 3, but a missing or weak supporting artifact can still cost you the section.

1. Integration Architecture Diagram

Purpose: Detailed view of all integration interfaces, including data flows, protocols, patterns, and error handling. This zooms into the arrows from your System Landscape.

What to Include

Element	Details
Source + target systems	For each integration point
Integration pattern	Request-Reply, Fire-and-Forget, Batch, Event-Driven, Pub-Sub
Protocol	REST, SOAP, Platform Events, CDC, Streaming API, Bulk API
Middleware	MuleSoft, cloud services, custom middleware layer
Data direction	Unidirectional or bidirectional arrows
Sync vs Async	For each interface
Frequency	Real-time, near-real-time, scheduled (cron), event-triggered
Error handling	Dead letter queues, retry logic, alerting, circuit breakers
Data transformation	Where and how data is mapped between systems
Volumes	Records/messages per interface per day

Interface Reference Table Pattern

The numbering technique

If your diagram gets too busy, number each integration (I-01, I-02…) on the diagram and create a companion table in Google Sheets with full details. Present both: diagram for visual story, table for technical depth. Judges appreciate this level of organization.

Interface	Source	Target	Pattern	Protocol	Sync/Async	Frequency	Volume	Error Handling
I-01	ERP	Salesforce	Batch	REST Bulk API	Async	Nightly	50K records	Retry 3x, DLQ, alert
I-02	Salesforce	DW	Event-Driven	CDC	Async	Real-time	10K/day	Platform Event replay
I-03	Portal	Salesforce	Request-Reply	REST API	Sync	Real-time	500 req/min	Circuit breaker, 429 retry

Integration Pattern Decision Matrix

Need	Pattern	Protocol Options
Instant response required	Request-Reply	REST, SOAP
No response needed	Fire-and-Forget	Platform Events, Outbound Message
Large data volumes	Batch	Bulk API, ETL, Data Loader
React to record changes	Event-Driven	CDC, Platform Events
Multiple consumers	Pub-Sub	Platform Events, Streaming API
Complex orchestration	Process Orchestration	MuleSoft, AWS Step Functions

Mandatory Checklist (verify before presenting)

Check	Pass?
MuleSoft/ESB shown as explicit layer between Salesforce and every external system?
Every arrow labeled with sync/async/batch timing?
Every arrow labeled with protocol (REST, SOAP, Platform Events, CDC, Bulk API)?
Error handling shown for each interface (retry, DLQ, alerting)?
Volumes per interface documented?
Legend included?

Common Mistakes

Integration gotchas

• No middleware layer: direct arrows from Salesforce to external systems without MuleSoft/ESB in between. Every Salesforce-to-external connection must route through the integration layer
• Unlabeled arrows: every arrow needs three labels: direction, timing (sync/async/batch), and protocol (REST/SOAP/Events). Use labels like “Sync REST”, “Async Platform Event”, “Batch ETL (nightly)”
• Happy path only: judges always ask “what happens when this fails at 2 AM?”
• No error handling: every interface needs retry logic, DLQ, and alerting
• No volumes: “how many records?” is a guaranteed question
• Saying “ETL” without specifics: name the tool, the steps, the schedule
• Ignoring API limits: Salesforce has daily API call limits; how does your design stay within them?
• Sync where async is appropriate: blocking calls for non-urgent data flows

Judge Q&A Targets

Question	Prep
”What happens when integration X fails?”	Retry count, DLQ, monitoring, manual recovery
”Why sync instead of async here?”	Latency requirement from scenario
”What are the API limits?“	100K calls/day (Enterprise), show you calculated
”How do you handle data conflicts?”	Last-write-wins, master system designation, conflict queue

Domains scored: Integration (D5), System Architecture (D1)

---

2. Identity & SSO Flow Diagram

Purpose: The authentication and authorization flow showing login sequences, identity federation, and SSO across systems. Show the actual step-by-step flow, not just “we use SAML.”

What to Include

Element	Details
Identity Provider (IdP)	Corporate AD, Okta, Azure AD, Salesforce as IdP, social login
Service Providers (SP)	Salesforce orgs, portals, external systems
Protocol	SAML 2.0, OAuth 2.0, OpenID Connect
Flow type	SP-initiated vs IdP-initiated
User provisioning	JIT, manual, automated via integration
MFA	Multi-factor approach per user type
Portal identity	How external users authenticate (separate IdP? self-registration?)
Token management	Access tokens, refresh tokens, session policies

SSO Flow Template (SAML SP-Initiated)

Figure 1. SP-initiated flow is the standard for bookmark-driven access: the user lands on Salesforce first, gets redirected to the IdP for authentication, and returns with a SAML assertion. Step 6 (JIT provisioning) is where dynamic profile, role, and permission set assignment happens based on assertion attributes.

Protocol Decision Quick-Ref

Scenario	Protocol	Flow
Internal users, corporate IdP	SAML 2.0	SP-initiated
External portal users, social login	OpenID Connect	SP-initiated
System-to-system (no user)	OAuth 2.0 JWT Bearer	Client Credentials
Mobile app authentication	OAuth 2.0	Web Server or Device Flow
Salesforce org-to-org	Named Credentials + OAuth	JWT Bearer
Marketing Cloud connect	OAuth 2.0	Web Server

Internal vs External Identity

Aspect	Internal Users	External (Portal) Users
IdP	Corporate (Okta, Azure AD)	Social, self-registration, or customer IdP
Protocol	SAML 2.0 typically	OpenID Connect or SAML
Provisioning	JIT or directory sync	Self-registration + approval
MFA	Corporate MFA policy	SMS/email verification
Session timeout	2-12 hours (corporate policy)	Shorter (30 min - 2 hours)
License	Full Salesforce licenses	Community/Experience Cloud licenses

Common Mistakes

Identity flow gotchas

• Saying “we use SSO” without showing the flow: judges expect the step-by-step sequence
• Not differentiating internal vs external: they have completely different flows
• Forgetting logout: session timeout, single logout (SLO), token revocation
• No MFA: multi-factor authentication is expected for all production access
• Confusing SAML roles: know which system is the IdP and which is the SP clearly
• Missing provisioning: how do user accounts get created? JIT? Manual? Automated sync?

Domains scored: Security (D2), System Architecture (D1)

---

3. Data Migration Strategy

Purpose: The plan for moving data from legacy systems to Salesforce, covering sequencing, tooling, validation, and rollback.

What to Include

Element	Details
Source systems	Where data comes from
Approach	Big-bang vs phased/incremental
ETL tooling	Data Loader, Informatica, Jitterbit, MuleSoft
Object load order	Parent objects first, junction objects last
Data cleansing	Dedup, validation, enrichment steps
External ID strategy	How records are matched between old and new systems
Volume estimates	Record counts per object
Validation	How you verify integrity post-migration
Rollback plan	What happens if migration fails midway
Cutover plan	When to switch, parallel run period

Load Sequence Rule

Figure 2. The load sequence enforces the parent-first rule: Users must exist before OwnerId references resolve, Accounts before Contacts, and both sides of a junction before the junction record. Loading files last prevents ContentVersion parent-ID failures that would otherwise require a full re-run.

The parent-first rule

Always load parent objects before children. Load junction objects after both related objects exist. Load attachments and files last. External IDs on every object enable upsert-based matching.

Migration Approach Decision

Factor	Big-Bang	Phased
Risk	Higher - all-or-nothing	Lower - incremental validation
Downtime	Single extended window	Multiple shorter windows
Complexity	Simpler plan, harder execution	Complex plan, easier execution
Data consistency	Guaranteed at cutover	Requires delta sync between phases
CTA recommendation	Small orgs, simple data	Large orgs, complex dependencies

Common Mistakes

Migration gotchas

• No external IDs: how will you match records between systems during migration?
• Wrong load order: loading Contacts before Accounts causes lookup failures
• No validation plan: how do you verify record counts, relationship integrity, data quality post-load?
• No rollback: judges ask “what if the migration fails halfway?” Have an answer
• Saying “extract, cleanse, transform, load” without specifics: this is a buzzword trap. Name the tools, the rules, the schedule

Domains scored: Data (D3), Integration (D5)

---

4. Governance & DevOps Framework

Purpose: Environment strategy, CI/CD pipeline, release management, and organizational governance. This covers all 6 objectives of Domain 6.

What to Include

Element	Details
Environments	Dev sandboxes, partial copy, full copy, staging, production
Branching strategy	Feature branches, integration, release, main
CI/CD pipeline	Source control -> build -> test -> deploy (with tool names)
Testing strategy	Unit, integration, UAT, regression (with coverage targets)
Release cadence	Sprint-based, quarterly, ad-hoc
Governance model	CoE, architecture review board, change advisory board
Code review	Peer review, automated analysis (PMD, ESLint)
Deployment tools	Salesforce CLI, change sets, Gearset, Copado, AutoRABIT

Environment Pipeline Pattern

Figure 3. Each promotion gate enforces a different quality control: code review at the PR stage, automated tests at Integration, business validation at UAT, and change advisory board approval before production. Staging with a full copy sandbox is mandatory for performance testing at production-scale data volumes.

Governance Quick-Ref

Governance Element	Purpose	Who
Center of Excellence (CoE)	Standards, best practices, training	Senior architects
Architecture Review Board	Design sign-off for major changes	CTAs, lead architects
Change Advisory Board (CAB)	Production release approval	IT leadership, business
Code Review Process	Quality gate before merge	Peer developers
Automated Code Analysis	Enforce standards (PMD, ESLint)	CI pipeline

Common Mistakes

Governance gotchas

• No sandbox refresh strategy: how often do you refresh? What data is included?
• Missing rollback plan: what happens if a production deploy fails?
• No testing in pipeline: automated tests must run before deployment, not after
• Vague governance: “we have a CoE” is not enough. Name the cadence, the stakeholders, the approval gates
• Ignoring metadata conflicts: parallel development streams cause merge conflicts. How do you handle them?

Judge Q&A Targets

Question	Prep
”How many sandboxes and what types?”	Developer (per dev), Partial Copy (integration + QA), Full Copy (staging)
“What is your branching strategy?”	Feature branches -> integration -> release -> main
”Where do automated tests run?”	On PR creation and before deployment to QA
”What is your rollback strategy?”	Quick deploy of last known good, metadata rollback via source control
”Who approves production releases?”	CAB with business and IT sign-off

Domains scored: Development Lifecycle (D6)

---

Supporting Artifacts Checklist

Before presenting, verify every supporting artifact passes this check:

Check	System Landscape	Integration	Identity	Migration	Governance
Titled with header?
Legend included?
Tied to requirements?
Error/failure paths?	N/A	Required	N/A	Required	Required
Volumes/counts?		Required		Required
Trade-offs annotated?

---

Sources

• Salesforce Diagramming Framework - architect.salesforce.com
• CTA Diagramming Framework - FlowRepublic
• Dealing with the Critical Piece of the CTA Board: Q&A - Apex Hours
• CTA Certification Guide & Tips - Salesforce Ben
• Brief Insights from a CTA Board Judge - Dinesh Yadav
• CTA Review Board Prep Winter ‘26 - TrailblazePrep