Artifact Process, Tools & Quality Standards

This guide covers presentation order, time allocation, tools usage, the Salesforce diagramming framework, artifact quality standards, domain-specific artifact requirements, and lessons from CTAs who passed and failed.

Slide	Artifact	Est. Time	What to Cover
1	Company Overview & Assumptions	2-3 min	Company context, core challenges, top 3-5 requirements, key assumptions
2	Org Strategy	1-2 min	Single org vs. multi-org decision, org purpose, translations, multi-currency
3	Actors & Licenses	2-3 min	All user types mapped to licenses with counts and key use cases
4	System Landscape	4-5 min	All systems, their roles, connections, and integration types
5	Role Hierarchy & Sharing	3-4 min	Role tree, OWD, sharing rules, portal security
6	Data Model	4-5 min	ERD with relationships, ownership, OWD annotations, LDV callouts
7	Integration Architecture	4-5 min	Detailed integration flows, patterns, protocols, error handling
8	Identity & SSO	2-3 min	Authentication flows, IdP/SP setup, portal identity
9	Business Requirements Coverage	3-4 min	How key requirements are met (LWCs, Apex, Flows, communities)
10	Data Migration	2-3 min	Migration strategy, sequencing, tooling, validation
11	Governance & DevOps	3-4 min	Environments, CI/CD, CoE, branching strategy, testing
12	Risks & Summary	2-3 min	Top risks with mitigations, summary of key decisions and trade-offs
	Total	~33-44 min	Aim for 35-40 minutes to leave buffer

Time Allocation: Splitting the 180 Minutes

Recommended Time Breakdown

Phase	Duration	Activity
Initial read	20-30 min	Read the entire scenario once. Do not write anything yet on the first pass. Absorb the big picture.
Second pass + extract	30-40 min	Re-read and extract: actors, systems, requirements, constraints, data volumes. Start drawing system landscape and actors immediately — “draw as you go”
Core diagrams	50-60 min	Build the Big 3 diagrams in Lucidchart: System Landscape, Data Model, Role Hierarchy/Sharing
Supporting artifacts	25-30 min	Build integration details, SSO flows, migration strategy, governance diagram
Slides + story	15-20 min	Organize artifacts into your presentation order in Google Slides, write key talking points
Review	10-15 min	Review every requirement in the scenario — did you address it? Check diagram readability. Prepare opening and closing statements

The “Draw As You Go” Strategy

This is the most widely recommended time-saving technique from successful candidates:

Page 1 of the scenario usually introduces the company, its users, and its existing systems. As soon as you read this, start drawing your System Landscape and Actors diagram. Do not wait until you finish reading.
As you encounter each requirement, add relevant elements to your diagrams. If a requirement mentions an integration with an ERP system, add it to your system landscape immediately.
By the time you finish reading the scenario, your diagrams should be 60-70% complete. You then spend focused time polishing, adding detail, and ensuring completeness.

What kills your time

Reading the entire scenario end-to-end, then starting diagrams from scratch. You will not have enough time to go through the scenario twice. Extract and draw simultaneously on the second pass.

Time Checkpoints

flowchart LR
    T0["0 min\nStart Reading"] --> T30["30 min\nFirst read done\nStart drawing"]
    T30 --> T60["60 min\nLandscape +\nActors done"]
    T60 --> T90["90 min\nERD + Role\nHierarchy done"]
    T90 --> T120["120 min\nAll core diagrams\nStart support"]
    T120 --> T150["150 min\nAll artifacts\nOrganize slides"]
    T150 --> T170["170 min\nFinal review\nCheck requirements"]
    T170 --> T180["180 min\nReady to\npresent"]

    style T90 fill:#e8a838,color:#fff
    style T180 fill:#2ecc71,color:#fff

Clock	You Should Have	If Not
30 min	First read done, starting to draw	Speed up reading — you are behind
60 min	System Landscape and Actors mostly complete	Prioritize these two — they frame everything
90 min	Data Model and Role Hierarchy mostly complete	You are at the halfway mark — stay focused
120 min	All core diagrams done, starting supporting artifacts	Cut lower-priority artifacts if needed
150 min	All artifacts done, organizing slides	You need 30 min to finalize
170 min	Final review — checking all requirements addressed	Last 10 min is review only
180 min	Ready to present

Tools Usage Guide

Lucidchart (Primary Diagramming Tool)

Lucidchart is the only approved diagramming tool. You must be proficient with it before exam day.

Essential Lucidchart skills to practice:

Skill	Why It Matters
Salesforce Shape Library	Use the official Salesforce shapes for all cloud products, objects, and icons. Judges expect standardized notation
Card-based diagramming	The Salesforce diagramming framework uses “Cards” as the primary building block (see below)
Headers	Every diagram must have a header with title, description, and optional legend
Connectors and pills	Use elbow connectors with labels (pills) for integration details
Nesting cards	Show containment (e.g., objects within an org, components within a system)
Color coding	Apply consistent colors: Salesforce blue, external systems gray, integration orange
Grouping and alignment	Keep diagrams clean with aligned elements and logical grouping
Speed	You should be able to create a full system landscape in under 20 minutes

Practice regimen: Create 2-3 practice diagrams per week in Lucidchart for at least 6-8 weeks before the exam.

Google Slides (Presentation Framework)

Use Google Slides to organize your presentation flow and add supporting text.

How to use Google Slides effectively:

Create one slide per major artifact/section
Embed or reference your Lucidchart diagrams (you can screenshot/export from Lucidchart)
Add bullet-point talking points — do not write full sentences you will read aloud
Use large, readable fonts (judges view through screen share)
Number your slides for easy reference during Q&A

Google Sheets (Supporting Tables)

Use Google Sheets for detailed tabular information that would clutter your diagrams.

Common uses:

License calculation table (actor type x license type x count = cost)
Integration reference table (interface number, source, target, pattern, protocol, frequency, volume)
OWD and sharing rules matrix (object x OWD x sharing rules)
Data migration sequence table (object, source, volume, dependencies, load order)
Requirements traceability matrix (requirement x how addressed x which artifact)

The interface reference technique

If adding all integration details to your diagram makes it too busy, number each integration interface on the diagram (I-01, I-02, etc.) and create a companion table in Google Sheets with full details. Use both during your presentation — the diagram for the visual story, the table for the technical depth. Judges appreciate this level of organization.

Paper and Pen (Optional Scratch Work)

Use for quick notes during the first read-through
Jot down questions, assumptions, and key requirements to remember
Sketch rough layout ideas before building in Lucidchart
Do not spend significant time here — your final artifacts must be digital

Salesforce Diagramming Framework

Salesforce has an official diagramming framework that aligns with how CTA judges expect diagrams to look. Understanding this framework gives you an edge.

The Four Diagram Levels (Inspired by C4 Model)

Level	Name	Scope	Detail	Audience
Level 1	System Landscape / Big Picture	Entire solution ecosystem	Low — products and connections, no internals	Executives, all stakeholders
Level 2	Solution Architecture	A subset of the landscape	Medium — products with integration details, behavior, functionality	Technical stakeholders
Level 3	Interaction / Process Flow	A specific process or interaction	High — time-based steps, data flows, numbered sequences	Technical teams
Level 4	Data Model / Entity Relationship	A specific data domain	Highest — objects, fields, relationships, cardinality	Developers, data architects

Standard Diagram Components

Every diagram should include these components from the Salesforce framework:

Header (Required):

Must occupy at least 10% of diagram height, spanning full width
Title: quickly understandable by the audience
Description: clear statement of what the diagram covers, its purpose, and its scope
Optional: company logo, author, legend/key explaining icons and symbols

Cards (Required):

Cards represent all properties in the diagram (systems, objects, concepts)
Required element: Card Title
Optional elements: Card Icon, Card Attributes (text-based details), Card Footer, Footer Icons
Cards can nest inside other cards to show containment or hierarchy
Cards are fully resizable with transparent or colored fills

Connectors (Required for relationship diagrams):

Use elbow connection lines; keep straight whenever possible for readability
Line styles indicate different connection types (solid, dashed)
Endpoints show direction and cardinality
Pills (labels on connectors) provide connection details — used especially in Solution Architecture and Process Flow diagrams

Layout principle: Read left to right and top to bottom. Convey messages concisely with appropriate information scope.

The Five Standard Diagram Types

Based on the official framework:

Capability Map — captures the product mix and key capabilities in a solution
System Landscape — captures products and technical systems involved in an implementation
Solution Architecture — includes products with integration, behavior, and functionality details
Interaction / Process Flow — captures time-based steps, data flows, or interactions with sequenced numbering
Data Model (ERD) — captures entities, objects, relationships, and concepts for metadata implementations

Accessibility Best Practices

Export diagrams as PDF for optimal screen reader compatibility
Follow WCAG guidelines: minimum 4.5:1 contrast ratio between background and text
Use the Salesforce color system 50-point rule: background color at least 50 points different from text color (on a 0-100 scale)

Mandatory Diagram Standards

These standards apply to every diagram you create. They are drawn from the Salesforce Diagramming Framework and reinforced by CTA coaching programs including FlowRepublic’s CTA Diagramming Guide.

Legends Are Mandatory

Every diagram must include a legend. This is not a nice-to-have — it is a required component of the Salesforce diagramming framework and a consistent marker that judges use to distinguish passing from failing artifacts.

Your legend must explain:

Color coding: what each color represents (Salesforce blue, external gray, integration orange, user channels green)
System status: which systems are new (being built), retiring (being decommissioned), or keeping (unchanged) — use distinct colors or border styles
Line styles: what solid vs dashed vs dotted lines mean
Icons: any iconography used for system types, user types, or technologies

A diagram without a legend forces judges to guess your conventions. That guessing costs you points.

Integration Layer Is Mandatory

An explicit integration/middleware layer (MuleSoft, ESB, API gateway) must appear in every System Landscape and Integration Architecture diagram. Approximately 95% of CTA scenarios involve multi-system integrations that require middleware.

Rules:

Never draw direct point-to-point arrows from Salesforce to an external system without middleware in between
The integration layer should be visually distinct (orange fill is the convention)
Label each connection through the middleware with the integration pattern (sync/async/batch) and protocol (REST, SOAP, Platform Events, CDC, ETL)
Even if the scenario text does not explicitly mention middleware, include it — real enterprise architectures always have an integration layer

Data Flow Direction Labels Are Mandatory

Every arrow on every diagram must indicate:

Direction: which way data flows (unidirectional or bidirectional)
Timing: sync, async, batch, near-real-time, event-driven
Protocol: REST, SOAP, Platform Events, CDC, Bulk API, ETL

Unlabeled arrows are a characteristic of failing artifacts. Judges should be able to understand the integration pattern by reading the diagram without your verbal explanation.

What Good vs. Bad Artifacts Look Like

Characteristics of Passing Artifacts

Trait	What It Looks Like
Readable	Large enough text and clear labels visible during screen share. Judges can understand the diagram without your explanation
Purposeful	Every element exists to communicate an architectural decision. No decorative clutter
Connected to requirements	You can point to any element and explain which requirement it addresses
Properly scoped	The right level of detail for the diagram type. System Landscape stays high-level; ERD goes deep
Consistent notation	Same colors, shapes, and conventions across all diagrams
Legends included	Color coding, system status (new/retiring/keeping), line styles, and icons all explained in a key
Integration layer shown	MuleSoft/ESB visible between Salesforce and all external systems — no direct point-to-point arrows
Data flow labels	Every arrow labeled with direction, timing (sync/async/batch), and protocol
Trade-offs visible	Annotations or callouts showing where you made deliberate trade-offs
Professional	Worthy of presenting to a CXO. Not necessarily beautiful, but organized and clear

Characteristics of Failing Artifacts

Trait	What It Looks Like
Unreadable	Tiny text, overlapping elements, no whitespace. Judges squint during screen share
Too busy	Every possible detail crammed into one diagram instead of layering across levels
Disconnected	Diagrams exist in isolation — no traceability to requirements
Missing legend	Colors and icons used inconsistently with no explanation; no system status indicators (new/retiring/keeping)
No integration layer	Direct arrows from Salesforce to ERP/DW with no middleware shown — signals a lack of enterprise architecture understanding
Unlabeled arrows	Connections without direction, timing (sync/async/batch), or protocol labels
Wrong level of detail	System Landscape shows individual Apex classes; ERD shows only object names without relationships
Incomplete	Missing major systems, objects, or integration points mentioned in the scenario
Buzzword-heavy	Labels like “Integration” or “Security” without any specifics
Untitled	No header describing what the diagram is and what scope it covers

The Readability Test

Before presenting, ask yourself: “If I put this diagram on screen for 10 seconds without speaking, could a judge understand what it represents?” If the answer is no, simplify.

Domain-Specific Artifact Requirements

Domain 1 — System Architecture Artifacts

Required: System Landscape diagram Supporting: Org strategy documentation (single vs. multi-org justification), license model, mobile architecture decisions, reporting/analytics approach, document management solution

What judges probe:

Why did you choose this mix of on-platform vs. off-platform?
What are the limitations of the platform features you chose?
Why this license type and not another?
How does your architecture handle mobile access?
What reporting options did you evaluate?

Domain 2 — Security Artifacts

Required: Role Hierarchy diagram, Identity/SSO flow diagram Supporting: OWD table, sharing rules matrix, portal security architecture, encryption approach, field-level security documentation

What judges probe:

Walk me through exactly how this sharing rule works
What happens if a user in role X needs to see records owned by role Y?
Why did you choose this OWD setting?
What if there are 50,000 portal users — how does sharing scale?
Explain the SSO flow step by step — what happens at each redirect?

Most commonly failed domain

Security, and specifically the sharing model, is the most commonly cited gap in failed candidates. Go deep on your Role Hierarchy and Sharing architecture. Be prepared to explain every OWD choice and every sharing rule.

Domain 3 — Data Artifacts

Required: Data Model / ERD Supporting: Data migration strategy, LDV analysis table, data volume estimates, archiving strategy

What judges probe:

Why Master-Detail vs. Lookup for this relationship?
How do you handle objects with 10M+ records?
What is your indexing and query optimization strategy for LDV?
Walk me through the migration sequence — what loads first and why?
How do you validate data integrity after migration?

Domain 4 — Solution Architecture Artifacts

Required: Business requirements coverage (how each requirement is met) Supporting: Declarative vs. programmatic decision matrix, AppExchange evaluation, off-platform component justification

What judges probe:

Why custom code instead of a declarative approach?
Did you evaluate AppExchange solutions? Which ones and why did you accept/reject them?
What is the trade-off between building this custom vs. buying?

Domain 5 — Integration Artifacts

Required: Integration Architecture diagram (detailed) Supporting: Integration reference table (interface inventory), error handling approach, data transformation logic

What judges probe:

What happens when this integration fails at 2 AM?
Why synchronous instead of asynchronous for this interface?
What is your retry and dead letter queue strategy?
How do you handle data conflicts between systems?
What are the API limits and how does your design stay within them?

Domain 6 — Development Lifecycle Artifacts

Required: Environment/deployment strategy diagram Supporting: CI/CD pipeline diagram, branching strategy, testing strategy, governance model, release plan

What judges probe:

How many sandboxes and what types?
What is your branching strategy?
Where in the pipeline do automated tests run?
How do you handle metadata conflicts between parallel development streams?
What is your rollback strategy if a release fails?
Who approves changes and how (governance)?

Domain 7 — Communication

No separate artifact — this domain is scored holistically across your entire presentation and Q&A performance. Your diagrams themselves are a communication artifact.

What judges assess:

Are your diagrams clear and well-labeled?
Do you tie every solution to a requirement?
Can you switch between business language and technical language?
Do you handle objections and pushback professionally?
Are your answers concise (Correct and Concise)?

Lessons from CTAs: What Successful and Failed Candidates Created

Successful Candidates

Jannis Bott (CTA — passed on second attempt):

First attempt: Extracted all requirements into Excel, struggled with narrative flow. Failed.
Second attempt: Introduced the company, outlined actors and system landscape first, then addressed each requirement while referencing diagrams. Drew diagrams immediately while reviewing the scenario. Passed.
Key lesson: “Draw as you go. You will not have time to read the entire scenario and then start diagramming.”

Melissa Shepard (CTA — passed on second attempt):

4x per week study sessions, 20-30 total mock boards, worked with hand-picked CTA judges.
Artifacts recommended: Project Overview, Actors/Licenses, Role Hierarchy, System Landscape with Integrations & Security, Data Model, Data Migration.
Key lesson: “Work on presenting requirements from the user perspective.”

Adam (CGI):

Finished presentation in 31 minutes 50 seconds, leaving 13+ minutes added to Q&A (total Q&A: 58 minutes 10 seconds).
Key lesson: “Streamline initial case review to spend more time on flip chart preparation.”
Warning: The board is completely silent during your presentation — no feedback, no nods, no comments.

Common Gaps in Failed Candidates

Section	Common Gaps
Security / Sharing Model	Most commonly cited failure area. Candidates cannot explain OWD choices, sharing rules, or how sharing scales
Integration	Shallow design — naming patterns without explaining error handling, retry logic, or failure scenarios
Large Data Volumes	Not addressing query optimization, indexing, skinny tables, archiving
Multi-Org Strategy	Not evaluating single vs. multi-org when the scenario hints at it

Artifact-Specific Failures

Missing error handling in integration diagrams — only showing the happy path
Data model without ownership annotations — judges cannot assess the sharing model
Role hierarchy too shallow — not showing how portal/community users fit in
System landscape missing systems — not including all systems mentioned in the scenario
System landscape missing integration layer — direct arrows from Salesforce to external systems with no MuleSoft/ESB shown
System landscape missing legend — no color coding key, no system status indicators (new/retiring/keeping)
No data volumes on the data model — judges cannot assess LDV risk
Migration strategy as buzzwords — saying “ETL” without specifying tools, sequence, validation, or rollback
Governance diagram missing — not addressing how ongoing changes will be managed after go-live
Unlabeled integration arrows — arrows without sync/async/batch labels and protocol names

Pre-Exam Preparation Checklist

Lucidchart Readiness (8-12 weeks before exam)

Activate the Salesforce Shape Library in your Lucidchart account
Practice creating a System Landscape from scratch in under 20 minutes
Practice creating an ERD from scratch in under 20 minutes
Practice creating a Role Hierarchy from scratch in under 15 minutes
Practice creating an Integration Architecture diagram in under 15 minutes
Practice creating an SSO flow diagram in under 10 minutes
Know the Salesforce standard Card, Header, and Connector components by heart
Develop your personal color scheme and use it consistently across all practice diagrams

Template Memorization (6-8 weeks before exam)

Memorize your 10-12 slide presentation structure
Know the exact talking points for each slide (not a script, but a structure)
Know your time allocation: when you should be at each checkpoint during prep
Prepare a standard opening statement template you can customize for any scenario
Prepare a standard closing summary template

Mock Board Milestones

Complete at least 3 mocks focusing on artifact creation only (no Q&A)
Complete at least 5 full mocks (prep + presentation + Q&A)
At least 2 mocks with CTA judges or experienced architects on the panel
Score consistently 75%+ across all 7 domains in mock evaluations
Final mock 5-7 days before exam day

Day-Before Preparation

Do not do a mock the day before — rest
Confirm your Zoom, Lucidchart, and Google Workspace access works
Prepare your physical space: clean desk, good lighting, camera at eye level
Set up a visible timer you can glance at during prep and presentation
Prepare water and a light snack for the 15-minute break

Artifact Process, Tools & Quality Standards

Recommended Presentation Order

The 12-Slide Presentation Template

Alternative Presentation Orders

Time Allocation: Splitting the 180 Minutes

Recommended Time Breakdown

The “Draw As You Go” Strategy

Time Checkpoints

Tools Usage Guide

Lucidchart (Primary Diagramming Tool)

Google Slides (Presentation Framework)

Google Sheets (Supporting Tables)

Paper and Pen (Optional Scratch Work)

Salesforce Diagramming Framework

The Four Diagram Levels (Inspired by C4 Model)

Standard Diagram Components

The Five Standard Diagram Types

Accessibility Best Practices

Mandatory Diagram Standards

Legends Are Mandatory

Integration Layer Is Mandatory

Data Flow Direction Labels Are Mandatory

What Good vs. Bad Artifacts Look Like

Characteristics of Passing Artifacts

Characteristics of Failing Artifacts

The Readability Test

Domain-Specific Artifact Requirements

Domain 1 — System Architecture Artifacts

Domain 2 — Security Artifacts

Domain 3 — Data Artifacts

Domain 4 — Solution Architecture Artifacts

Domain 5 — Integration Artifacts

Domain 6 — Development Lifecycle Artifacts

Domain 7 — Communication

Lessons from CTAs: What Successful and Failed Candidates Created

Successful Candidates

Common Gaps in Failed Candidates

Artifact-Specific Failures

Pre-Exam Preparation Checklist

Lucidchart Readiness (8-12 weeks before exam)

Template Memorization (6-8 weeks before exam)

Mock Board Milestones

Day-Before Preparation