Supporting & Situational Artifacts
These artifacts are required for a complete presentation. Tier 2 artifacts are typically presented more quickly (2-4 minutes each). Tier 3 artifacts are situational and can differentiate a strong presentation.
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 will check whether you chose appropriate licenses and understood 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, 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 you to go far beyond naming the integration pattern — you must show the complete 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, Heroku, 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 the 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 you to understand the specific flow — the sequence of redirects, assertions, and token exchanges — not just say “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 that you understand the full lifecycle — not just “extract, cleanse, transform, and load” as buzzwords, but the 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 you understand 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, SFDX, 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
These artifacts are not always required but can differentiate a strong presentation 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, 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.