Skip to content
SF CTA Study Hub

Decision Guides

These decision flowcharts are the practical tools a CTA uses when facing data architecture choices. Each diagram encodes the reasoning process — use them to structure your thinking during the review board and to explain your decisions to stakeholders.

Lookup vs Master-Detail

The most common relationship decision on the platform. Every object relationship starts here.

graph TD
    A[New relationship<br/>needed between<br/>Object A and Object B] --> B{Is Object B meaningless<br/>without Object A?}
    B -->|No — B exists<br/>independently| C[LOOKUP]
    B -->|Yes — B is always<br/>a child of A| D{Need roll-up<br/>summaries on A?}
    D -->|Yes| E{Already have 2 MD<br/>relationships on B?}
    D -->|No| F{Should B inherit<br/>sharing from A?}
    E -->|Yes — at limit| G[LOOKUP + DLRS<br/>or Flow roll-ups]
    E -->|No| H[MASTER-DETAIL]
    F -->|Yes — security<br/>requires it| H
    F -->|No — B has its<br/>own sharing model| I{Can B ever exist<br/>without A populated?}
    I -->|Yes — field<br/>optional| C
    I -->|No — always<br/>required| J{Need cascade<br/>delete?}
    J -->|Yes| H
    J -->|No| C

    style C fill:#4c6ef5,color:#fff
    style H fill:#51cf66,color:#fff
    style G fill:#ffd43b,color:#333

Key Factors Summary

FactorPoints to Master-DetailPoints to Lookup
Child meaningless without parentYesNo
Roll-up summaries neededYes (native)No (need DLRS/Flow)
Sharing inheritance neededYesNo
Child needs its own ownerNoYes
Field can be blankNeverSometimes
Cascade delete desiredYesNo
Reparenting neededRarelyOften

Standard vs Custom Objects

Before creating a custom object, exhaust standard object options.

graph TD
    A[New business entity<br/>to model] --> B{Does a standard object<br/>represent this concept?}
    B -->|Yes| C{Do you need the<br/>standard object's<br/>built-in features?}
    B -->|No| D[CUSTOM OBJECT]
    C -->|Yes — lead conversion,<br/>forecasting, etc.| E[STANDARD OBJECT<br/>with customization]
    C -->|No — just the<br/>name matches| F{Would using it confuse<br/>other features or AppExchange?}
    F -->|Yes| D
    F -->|No| G{Would record types<br/>handle the difference?}
    G -->|Yes| E
    G -->|No| H{Would it exceed<br/>field limits or create<br/>a God Object?}
    H -->|Yes| D
    H -->|No| E

    style D fill:#4c6ef5,color:#fff
    style E fill:#51cf66,color:#fff

Decision Criteria

CriterionStandard ObjectCustom Object
Built-in process supportLead conversion, Opportunity stages, Case escalationMust build from scratch
AppExchange compatibilityMost packages expect standard objectsMay need custom mapping
User familiarityUsers know “Accounts” and “Contacts”Requires training
Schema flexibilityLimited by existing fieldsFull control
Governor limit implicationsSome have higher limitsStandard limits

Archival Strategy

When data volume grows, choose the right archival approach.

graph TD
    A[Data volume growing<br/>beyond LDV thresholds] --> B{Is the data still<br/>actively accessed<br/>by users?}
    B -->|Yes — daily| C[Optimize queries<br/>indexes, skinny tables]
    B -->|Occasionally —<br/>monthly| D{Does it need to<br/>be queryable from<br/>within Salesforce?}
    B -->|Rarely — annual<br/>or compliance only| E{Compliance or<br/>legal retention<br/>requirement?}
    D -->|Yes| F{Volume < 1B?}
    D -->|No| G[Export to external<br/>data lake]
    F -->|Yes| H[BIG OBJECTS<br/>on-platform archival]
    F -->|No| I[EXTERNAL STORAGE<br/>+ Salesforce Connect]
    E -->|Yes| J{Must remain<br/>on Salesforce<br/>platform?}
    E -->|No| K[DELETE<br/>hard delete after<br/>export backup]
    J -->|Yes| H
    J -->|No| L[Export to compliant<br/>external storage]

    style C fill:#51cf66,color:#fff
    style H fill:#4c6ef5,color:#fff
    style I fill:#ffd43b,color:#333
    style K fill:#ff6b6b,color:#fff
    style G fill:#868e96,color:#fff

Migration Approach

Choose the right cutover strategy based on risk tolerance and constraints.

graph TD
    A[Migration Required] --> B{Total data volume?}
    B -->|< 10M records| C{Downtime window<br/>available?}
    B -->|10M - 100M records| D{Multiple source<br/>systems?}
    B -->|> 100M records| E[PHASED MIGRATION<br/>mandatory — volume<br/>too large for single cut]
    C -->|Yes — weekend<br/>or holiday| F[BIG BANG<br/>single cutover event]
    C -->|No — always on| G[PHASED MIGRATION<br/>by object or<br/>business unit]
    D -->|Yes — 3+<br/>source systems| H{Systems<br/>interdependent?}
    D -->|No — 1-2<br/>sources| C
    H -->|Yes| I[PARALLEL RUN<br/>both systems live<br/>until validated]
    H -->|No| G

    style F fill:#51cf66,color:#fff
    style G fill:#4c6ef5,color:#fff
    style I fill:#ffd43b,color:#333
    style E fill:#ff6b6b,color:#fff

Strategy Quick Reference

StrategyBest WhenRisk LevelCost
Big BangSmall-medium volume, clear cutover windowHigh (all-or-nothing)Low
PhasedLarge volume, multiple objects/BUsMedium (incremental)Medium
Parallel RunHigh risk, must validate before switchLow (fallback available)High

Person Accounts Decision

Person Accounts is an irreversible decision. Use this flowchart to evaluate carefully.

graph TD
    A[B2C requirement<br/>identified] --> B{Do individual customers<br/>need Account-level features?}
    B -->|No — Contact<br/>fields suffice| C[Use Contacts with<br/>a shared or<br/>individual Account]
    B -->|Yes — teams, hierarchy,<br/>entitlements on individual| D{Is the org<br/>already in production<br/>with B2B data?}
    D -->|No — greenfield| E{Will the org ever<br/>need B2B Account-Contact<br/>model too?}
    D -->|Yes — existing<br/>B2B data| F{Can you tolerate<br/>the impact on existing<br/>code and integrations?}
    E -->|No — pure B2C| G[ENABLE PERSON<br/>ACCOUNTS]
    E -->|Yes — hybrid| H{Can you manage<br/>complexity of both<br/>models in one org?}
    H -->|Yes| G
    H -->|No| I[Consider separate<br/>B2B and B2C orgs]
    F -->|Yes — willing to<br/>refactor| J{Have you audited<br/>all AppExchange packages<br/>for compatibility?}
    F -->|No| C
    J -->|Yes — all compatible| G
    J -->|No — some break| K[Address package<br/>incompatibility first<br/>or choose Contacts]

    style G fill:#ff6b6b,color:#fff
    style C fill:#51cf66,color:#fff
    style I fill:#4c6ef5,color:#fff

Irreversible

Enabling Person Accounts cannot be undone. Once enabled, every integration, trigger, report, and AppExchange package must handle both Person Accounts and Business Accounts. This decision is permanent.

Normalized vs Denormalized

On the Salesforce platform, normalization trade-offs differ from traditional databases because SOQL has relationship query limits and cross-object operations have governor limits.

graph TD
    A[Data model design<br/>decision] --> B{How many distinct<br/>entities are involved?}
    B -->|2-3 tightly coupled| C{Will they always be<br/>queried together?}
    B -->|4+ distinct entities| D[NORMALIZE<br/>separate objects with<br/>relationships]
    C -->|Yes — always| E{Any entity accessed<br/>independently?}
    C -->|No — sometimes<br/>separate| D
    E -->|No| F{Record volume<br/>concern?}
    E -->|Yes| D
    F -->|Low volume| G[DENORMALIZE<br/>combine into fewer objects]
    F -->|High volume —<br/>many fields per record| H{Formula fields<br/>can bridge?}
    H -->|Yes| D
    H -->|No| I[Selective denormalization<br/>with sync triggers]

    style D fill:#4c6ef5,color:#fff
    style G fill:#51cf66,color:#fff
    style I fill:#ffd43b,color:#333

Platform-Specific Normalization Factors

FactorFavors NormalizationFavors Denormalization
SOQL relationship queriesLimited to 1 level parent, 1 level childSingle object = simpler queries
Governor limitsMultiple DML = more limit consumptionSingle DML = fewer limits
Sharing modelEach object has independent sharingOne sharing model for combined data
Field countSpread across objectsRisk hitting 800 field limit
ReportingComplex report types neededSingle object = simpler reports
Data volumeEach object can scale independentlyOne large table = LDV sooner
MaintenanceMore objects to maintainFewer objects but larger

Data Virtualization vs ETL

When external data is needed in Salesforce, choose the access pattern.

graph TD
    A[External data needed<br/>in Salesforce] --> B{Data freshness<br/>requirement?}
    B -->|Must be real-time<br/>seconds| C{Write access<br/>needed?}
    B -->|Near real-time<br/>minutes| D{Volume?}
    B -->|Batch is OK<br/>hours/daily| E[ETL REPLICATION<br/>scheduled sync]
    C -->|Yes| F[REPLICATE + 2-WAY SYNC<br/>middleware required]
    C -->|No| G[SALESFORCE CONNECT<br/>virtualization]
    D -->|< 100K records| H[ETL REPLICATION<br/>small volume sync]
    D -->|> 100K records| I{Reporting needed?}
    I -->|Standard reports| H
    I -->|Reference only| G
    I -->|Advanced analytics| J[DATA CLOUD<br/>unified analytics]

    style E fill:#51cf66,color:#fff
    style G fill:#4c6ef5,color:#fff
    style F fill:#ffd43b,color:#333
    style H fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

Quick Reference

ApproachFreshnessReportingWriteComplexityCost
Salesforce ConnectReal-timeLimitedNoLowConnect license
ETL ReplicationBatchFullVia syncMediumETL tool
2-Way SyncNear real-timeFullYesHighMiddleware
Data CloudNear real-timeAdvancedLimitedMediumData Cloud license

How to Use These Guides on the CTA Exam

These decision flowcharts are not just reference material — they represent the structured thinking process that CTA examiners want to see:

  1. Start at the top — Frame the decision with the business requirement
  2. Walk through each branch — Explain which path you took and why
  3. State the outcome — Name the specific pattern or technology you chose
  4. Acknowledge alternatives — Mention the paths you did not take and why

Review board technique

When presenting, you can literally say: “I evaluated whether to use a lookup or master-detail by considering five factors: whether the child is meaningful without the parent, whether I need roll-ups, sharing inheritance requirements, reparenting needs, and cascade delete behavior. Based on these factors, I chose master-detail because…”

Sources