Skip to content
SF CTA Study Hub

Development Lifecycle Decision Guides

Visual decision flowcharts for the most common development lifecycle choices a CTA faces. These diagrams help systematize decisions that are otherwise made ad-hoc, and they demonstrate architectural rigor to the review board.

Branching Strategy Decision

Use this when choosing between GitFlow, trunk-based development, or a hybrid approach for a Salesforce project.

flowchart TD
    Start([Choose Branching<br/>Strategy]) --> Q1{How large is the<br/>development team?}
    Q1 -->|"1-5 developers"| Q2{Release cadence?}
    Q1 -->|"6-15 developers"| Q3{Release cadence?}
    Q1 -->|"15+ developers"| Q4{Multiple independent<br/>workstreams?}

    Q2 -->|Continuous| R1[Trunk-Based with<br/>Feature Flags]
    Q2 -->|"Weekly/Bi-weekly"| R2[Simple Feature<br/>Branch Model]
    Q2 -->|"Monthly+"| R3[Modified GitFlow]

    Q3 -->|Continuous| R4[Trunk-Based with<br/>Feature Flags + CI Gates]
    Q3 -->|"Weekly/Bi-weekly"| R3
    Q3 -->|"Monthly+"| R5[Full GitFlow]

    Q4 -->|Yes| R6[GitFlow per Workstream<br/>with Integration Branch]
    Q4 -->|No| R5

    style R1 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R2 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R3 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style R4 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style R5 fill:#f4a261,stroke:#d4823e,color:#000
    style R6 fill:#e76f51,stroke:#c45a3f,color:#fff

Legend: Green = Simple (less overhead) | Teal = Moderate | Orange = Complex | Red = Most Complex

Branch Strategy Quick Reference

StrategyBest ForOverheadRisk
Trunk-BasedSmall team, continuous delivery, mature CI/CDLowMedium (requires feature flags)
Feature BranchSmall-medium team, regular releasesLow-MediumLow
Modified GitFlowMedium team, scheduled releasesMediumLow
Full GitFlowLarge team, infrequent releases, multiple environmentsHighLow
GitFlow + WorkstreamsVery large team, independent feature setsVery HighLow

CI/CD Tool Selection Decision

Use this when choosing a CI/CD tool for a Salesforce implementation.

flowchart TD
    Start([Select CI/CD<br/>Tool]) --> Q1{Team's DevOps<br/>maturity?}
    Q1 -->|"Low -- admin-centric"| Q2{Budget for<br/>tooling?}
    Q2 -->|Available| R1[Copado or Gearset<br/>- SF-native, guided UX]
    Q2 -->|Limited| R2[Change Sets + Manual<br/>Process - Plan to Modernize]

    Q1 -->|"Medium -- some dev experience"| Q3{Existing CI/CD<br/>platform?}
    Q3 -->|GitHub| R3[GitHub Actions +<br/>Salesforce CLI]
    Q3 -->|Azure DevOps| R4[Azure Pipelines +<br/>Salesforce CLI]
    Q3 -->|GitLab| R5[GitLab CI +<br/>Salesforce CLI]
    Q3 -->|None| Q4{Preference for<br/>SF-native tool?}
    Q4 -->|Yes| R1
    Q4 -->|No| R3

    Q1 -->|"High -- full DevOps team"| Q5{Package-based<br/>development?}
    Q5 -->|Yes| R6[GitHub Actions or GitLab CI<br/>+ Unlocked Packages]
    Q5 -->|No| Q6{Need compliance<br/>tracking?}
    Q6 -->|Yes| R7[Copado + Compliance<br/>Module]
    Q6 -->|No| R3

    style R1 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style R2 fill:#e76f51,stroke:#c45a3f,color:#fff
    style R3 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R4 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R5 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R6 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R7 fill:#4ecdc4,stroke:#3ab5ad,color:#000

Legend: Green = General-purpose CI/CD | Teal = Salesforce-native CI/CD | Red = Legacy (plan to modernize)

Sandbox Strategy Decision

Use this when designing the environment topology for a Salesforce implementation.

flowchart TD
    Start([Design Environment<br/>Strategy]) --> Q1{Team size?}
    Q1 -->|"1-5"| S1{Need integration<br/>testing?}
    S1 -->|Yes| R1["3 Dev Sandboxes<br/>+ 1 Partial (SIT)<br/>+ 1 Partial (UAT)"]
    S1 -->|No| R2["3 Dev Sandboxes<br/>+ 1 Partial (UAT)"]

    Q1 -->|"6-15"| S2{Multiple<br/>workstreams?}
    S2 -->|Yes| R3["10 Dev + Scratch Orgs<br/>+ 2 Partial (SIT per stream)<br/>+ 1 Partial (UAT)<br/>+ 1 Full (Staging)"]
    S2 -->|No| R4["8 Dev + Scratch Orgs<br/>+ 1 Partial (SIT)<br/>+ 1 Partial (UAT)<br/>+ 1 Full (Staging)"]

    Q1 -->|"15+"| S3{Performance testing<br/>required?}
    S3 -->|Yes| R5["15+ Dev + Scratch Orgs<br/>+ 2 Partial (SIT)<br/>+ 1 Partial (UAT)<br/>+ 1 Full (Staging)<br/>+ 1 Full (Perf)"]
    S3 -->|No| R3

    style R1 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R2 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R3 fill:#f4a261,stroke:#d4823e,color:#000
    style R4 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style R5 fill:#e76f51,stroke:#c45a3f,color:#fff

Legend: Green = Minimal | Teal = Standard | Orange = Enterprise | Red = Large Enterprise

Change Sets vs CLI Decision

Use this when evaluating whether an org should continue using change sets or migrate to CLI-based deployment.

flowchart TD
    Start([Deployment Method<br/>Decision]) --> Q1{Does the org use<br/>source control?}
    Q1 -->|No| Q2{Plan to adopt<br/>source control?}
    Q2 -->|Yes| R1[Adopt SF CLI + Git<br/>Phase out Change Sets]
    Q2 -->|No| Q3{Team composition?}
    Q3 -->|Admins only| R2[Change Sets OK<br/>for now - plan modernization]
    Q3 -->|Mix of admins + devs| R1

    Q1 -->|Yes| Q4{Existing deployment<br/>automation?}
    Q4 -->|Yes| R3[Use SF CLI in<br/>existing CI/CD]
    Q4 -->|No| Q5{Team skill level?}
    Q5 -->|Comfortable with CLI| R3
    Q5 -->|Prefers GUI| R4[Gearset or Copado<br/>GUI-based deployment]

    Q1 -->|Partial| R1

    style R1 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R2 fill:#e76f51,stroke:#c45a3f,color:#fff
    style R3 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R4 fill:#4ecdc4,stroke:#3ab5ad,color:#000

Legend: Green = CLI/Automation | Teal = GUI-based tooling | Red = Legacy (acceptable short-term only)

Testing Approach Decision

Use this when determining the testing strategy for a Salesforce implementation.

flowchart TD
    Start([Define Testing<br/>Strategy]) --> Q1{What is being<br/>tested?}

    Q1 -->|Apex code| A1[Apex Unit Tests<br/>- isTest, TestSetup<br/>- 85%+ coverage target]
    Q1 -->|LWC components| A2[Jest Unit Tests<br/>- Component rendering<br/>- Event handling]
    Q1 -->|Flows| A3{Complex or<br/>simple Flow?}
    A3 -->|Complex| A4[Flow Debug +<br/>Apex Integration Test<br/>via Invocable]
    A3 -->|Simple| A5[Flow Debug +<br/>Manual Test Script]

    Q1 -->|Integrations| A6[Mock Callout Tests<br/>+ E2E Integration<br/>Test in SIT]
    Q1 -->|User journeys| A7{Automation<br/>justified?}
    A7 -->|Yes| A8[Provar or Copado RT<br/>Automated E2E]
    A7 -->|No| A9[Manual UAT<br/>with Test Scripts]

    Q1 -->|Performance| A10{LDV scenario?}
    A10 -->|Yes| A11[Full Copy Sandbox<br/>Load + Query Testing]
    A10 -->|No| A12[Partial Copy<br/>Spot-Check Performance]

    style A1 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style A2 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style A4 fill:#f4a261,stroke:#d4823e,color:#000
    style A5 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style A6 fill:#f4a261,stroke:#d4823e,color:#000
    style A8 fill:#e76f51,stroke:#c45a3f,color:#fff
    style A9 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style A11 fill:#e76f51,stroke:#c45a3f,color:#fff
    style A12 fill:#4ecdc4,stroke:#3ab5ad,color:#000

Legend: Green = Fully automated | Teal = Semi-automated | Orange = Hybrid | Red = Resource-intensive

Governance Structure Decision

Use this when determining the right governance model for a Salesforce implementation.

flowchart TD
    Start([Define Governance<br/>Structure]) --> Q1{Organization size?}
    Q1 -->|"Small (< 100 SF users)"| R1[Lightweight Governance<br/>- Single admin/architect<br/>- Informal review process<br/>- Quarterly standards review]
    Q1 -->|"Medium (100-1000 SF users)"| Q2{Multiple business<br/>units using SF?}
    Q2 -->|No| R2[Centralized CoE<br/>- ARB monthly<br/>- CAB per release<br/>- RACI for key activities]
    Q2 -->|Yes| R3[Hybrid CoE<br/>- Central standards team<br/>- BU delivery teams<br/>- ARB bi-weekly<br/>- CAB per deployment]
    Q1 -->|"Large (1000+ SF users)"| Q3{Multi-org or<br/>single org?}
    Q3 -->|Single org| R3
    Q3 -->|Multi-org| R4[Federated CoE<br/>- Central architecture team<br/>- Org-specific delivery teams<br/>- Cross-org ARB monthly<br/>- Org-level CAB per deployment]

    style R1 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R2 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style R3 fill:#f4a261,stroke:#d4823e,color:#000
    style R4 fill:#e76f51,stroke:#c45a3f,color:#fff

Deployment Rollback Decision

One of the most commonly-struggled topics in CTA scenarios. The review board often asks: “What is your rollback plan?” This decision tree helps determine the right rollback approach.

flowchart TD
    Start([Production Issue<br/>Detected Post-Deploy]) --> Q1{Severity?}

    Q1 -->|Critical<br/>System down| R1[Immediate Rollback<br/>Emergency CAB approval]
    Q1 -->|High<br/>Major feature broken| Q2{Deployment method?}
    Q1 -->|Medium/Low<br/>Cosmetic or minor| R2[Forward-Fix<br/>Deploy patch in<br/>next window]

    Q2 -->|Unlocked Packages| R3[Install Previous<br/>Package Version<br/>sf package install]
    Q2 -->|CLI Deployment| Q3{Destructive changes<br/>included?}
    Q2 -->|Change Sets| R4[Manual Reversal<br/>Redeploy prior config<br/>No automated rollback]

    Q3 -->|No| R5[Redeploy Previous<br/>Git Commit<br/>sf project deploy]
    Q3 -->|Yes| R6[Manual Recovery<br/>Recreate deleted<br/>components + redeploy]

    R1 --> Q2

    style R1 fill:#e76f51,stroke:#c45a3f,color:#fff
    style R3 fill:#2d6a4f,stroke:#1b4332,color:#fff
    style R4 fill:#e76f51,stroke:#c45a3f,color:#fff
    style R5 fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style R6 fill:#e76f51,stroke:#c45a3f,color:#fff
    style R2 fill:#2d6a4f,stroke:#1b4332,color:#fff

Destructive Changes Block Rollback

Destructive changes (deleted fields, objects, classes) are the biggest rollback risk. Once metadata is deleted in production, restoring it requires manual recreation — there is no automated undo. This is why every deployment plan must document destructive changes separately and why they require explicit CAB approval.

How to Use These Guides in a CTA Scenario

  1. Identify the lifecycle decisions required by the scenario (not all will be relevant)
  2. Walk through each relevant flowchart with the scenario’s specific constraints
  3. Document your path and the answers to each decision question
  4. Present the decisions as part of your governance and DevOps architecture
  5. Connect decisions to risk mitigation — many lifecycle choices directly reduce project risk

Review Board Strategy

In the CTA Review Board, governance and DevOps are often combined into a single artifact section. Show your environment topology diagram, your CI/CD pipeline, and your governance structure together to demonstrate a cohesive lifecycle strategy.

Sources