Supporting & Situational Artifacts
A complete presentation needs these artifacts. Tier 2 artifacts are typically covered faster (2-4 minutes each). Tier 3 artifacts are situational and can set a strong presentation apart.
Tier 2: Essential Supporting Artifacts
4. Actors & Licenses Diagram
What it is: A mapping of all user types (actors) to their Salesforce license types, access requirements, and approximate user counts.
Why it matters: License selection affects cost, capability, and architectural options. Judges check whether the chosen licenses are appropriate and whether the candidate understands the capabilities and constraints of each.
What to include:
| Element | Details |
|---|---|
| Internal user types | Sales reps, service agents, managers, admins, executives |
| External user types | Customers, partners, suppliers, community members |
| License type per actor | Sales Cloud, Service Cloud, Platform, Community (Customer/Partner/Channel), Identity |
| Feature licenses | Knowledge, Field Service, Heroku Connect (sustaining mode - end-of-sale Feb 2026), Einstein, etc. |
| User counts | Approximate numbers per actor type |
| Key use cases per actor | What each actor does in the system (1-2 bullet points) |
Maps to domains: System Architecture (D1), Security (D2)
5. Integration Architecture Diagram
What it is: A detailed view of all integration interfaces, showing data flows, protocols, patterns, error handling, and orchestration.
Why it matters: Integration is one of the most commonly failed sections. Judges expect candidates to go well beyond naming the integration pattern, showing the full flow including error handling and retry logic.
What to include:
| Element | Details |
|---|---|
| Source and target systems | For each integration |
| Integration pattern | Request-Reply, Fire-and-Forget, Batch, Event-Driven, Publish-Subscribe |
| Protocol | REST, SOAP, Platform Events, Change Data Capture, Streaming API |
| Middleware | MuleSoft, cloud services, custom middleware |
| Data direction | Which way data flows (unidirectional or bidirectional) |
| Sync vs. Async | For each integration |
| Frequency / trigger | Real-time, near-real-time, scheduled, event-triggered |
| Error handling | Dead letter queues, retry logic, alerting, circuit breakers |
| Data transformation | Where and how data is transformed between systems |
| Volumes | Message/record volumes per integration |
Diagram best practices:
- If the system landscape already shows high-level integration arrows, this diagram zooms into the detail
- Always show MuleSoft/ESB as an explicit layer between Salesforce and every external system. Do not draw direct point-to-point arrows. Even if the System Landscape already shows middleware, the Integration Architecture diagram must make the middleware layer prominent with specific integration flows passing through it
- Number each integration interface and create a reference table with full details
- Show the sequence of steps for complex integrations (numbered arrows)
- Label every data flow arrow with sync/async/batch. Judges should be able to tell the integration timing pattern at a glance without reading a companion table. Use clear labels like “Sync REST”, “Async Platform Event”, “Batch ETL (nightly)”, or “Near-RT CDC”
- Include error/failure paths, not just the happy path
- Call out asynchronous processing explicitly (queues, batches)
Maps to domains: Integration (D5), System Architecture (D1)
6. Identity & SSO Flow Diagram
What it is: The authentication and authorization flow showing how users log in, how identity is federated, and how SSO works across systems.
Why it matters: Identity management is a critical security domain objective. Judges expect understanding of the specific flow (the sequence of redirects, assertions, and token exchanges), not just “we use SSO with SAML.”
What to include:
| Element | Details |
|---|---|
| Identity Provider (IdP) | Who is the IdP (corporate AD, Okta, Salesforce as IdP, social login) |
| Service Providers (SP) | Salesforce orgs, portals, external systems acting as SPs |
| Protocol | SAML 2.0, OAuth 2.0, OpenID Connect, Delegated Authentication |
| Flow type | SP-initiated vs. IdP-initiated |
| User provisioning | JIT provisioning, manual, automated via integration |
| MFA | Multi-factor authentication approach |
| Portal/Community identity | How external users authenticate (separate IdP? self-registration?) |
| Token management | Access tokens, refresh tokens, session management |
Diagram best practices:
- Use a sequence diagram or numbered flow showing the exact steps
- Label each step (redirect, assertion, token exchange)
- Show different flows for internal vs. external users
- Include logout and session timeout handling
- Reference specific OAuth flows by name (Web Server, JWT Bearer, Device)
Maps to domains: Security (D2), System Architecture (D1)
7. Data Migration Strategy Diagram
What it is: The plan for migrating data from legacy systems into Salesforce, including sequencing, tooling, and validation.
Why it matters: Migration is deceptively complex. Judges want to see understanding of the full lifecycle, not just “extract, cleanse, transform, and load” as buzzwords, but specific steps within each phase.
What to include:
| Element | Details |
|---|---|
| Source systems | Where data is coming from |
| Migration approach | Big-bang vs. phased/incremental |
| ETL tooling | Data Loader, Informatica, Jitterbit, MuleSoft, custom scripts |
| Object load sequence | Which objects must be loaded first (Accounts before Contacts before Opportunities) |
| Data cleansing rules | Deduplication, validation, enrichment steps |
| External ID strategy | How records are matched between old and new systems |
| Volume estimates | How many records per object |
| Validation approach | How you verify data integrity post-migration |
| Rollback plan | What happens if migration fails partway through |
| Cutover plan | When to switch over, parallel run period |
Maps to domains: Data (D3), Integration (D5)
8. Development Lifecycle & Governance Diagram
What it is: The environment strategy, CI/CD pipeline, release management, and governance framework.
Why it matters: This diagram covers Domain 6 (Development Lifecycle), which has 6 objectives. Judges evaluate whether the candidate understands enterprise-grade development practices, not just developer sandboxes.
What to include:
| Element | Details |
|---|---|
| Environment strategy | Developer sandboxes, partial copy, full copy, staging, production |
| Branching strategy | Feature branches, integration branch, release branch |
| CI/CD pipeline | Source control, automated builds, automated testing, deployment automation |
| Testing strategy | Unit tests, integration tests, UAT, regression testing |
| Release cadence | Sprint-based, quarterly, ad-hoc |
| Governance model | Center of Excellence, architecture review board, change advisory board |
| Code review process | Peer review, automated code analysis (PMD, ESLint) |
| Deployment tools | Salesforce CLI (sf), change sets, Gearset, Copado, AutoRABIT |
Diagram best practices:
- Show the flow from developer to production as a pipeline diagram
- Include sandbox refresh strategy
- Show where automated tests run in the pipeline
- Call out the governance checkpoints (design review, code review, architecture sign-off)
Maps to domains: Development Lifecycle (D6)
Tier 3: Situational Artifacts
Not always required, but these artifacts can set a strong presentation apart when the scenario calls for them.
9. Business Process Flow
When to include: When the scenario describes complex business processes that span multiple systems or user roles.
What to show: Step-by-step process flow showing actors, system interactions, decision points, and handoffs. Use swimlane diagrams to show which actor or system handles each step.
10. Reporting & Analytics Architecture
When to include: When the scenario has significant reporting requirements, especially cross-system analytics.
What to show: Where reports are generated (Salesforce Reports, Einstein Analytics/CRM Analytics (formerly Tableau CRM), Tableau, external BI tools), data sources feeding each reporting layer, and any ETL needed for reporting.
11. Project Risks & Mitigations
When to include: Always - but this can be a simple table rather than a diagram.
What to show: Top 5-8 project risks with probability, impact, mitigation strategy, and contingency plan.
12. Company Overview / Executive Summary
When to include: As the opening slide to set business context.
What to show: 3-5 bullet points capturing the company, its industry, the core business challenge, key constraints, and your architectural philosophy for the solution.
Related Topics
- The Big 3 Diagrams: the highest-priority artifacts that supporting artifacts complement
- Artifact Process & Quality Standards: time allocation and quality standards for all artifacts
- Integration Patterns: source content for Integration Architecture diagram
- Identity & SSO: source content for the Identity and SSO flow diagram
- Data Migration: source content for the Data Migration Strategy artifact
- Development Lifecycle: source content for the Governance and DevOps diagram
- Licensing: source content for the Actors and Licenses artifact
Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.