Decision Guides

These decision flowcharts are practical tools for working through data architecture choices. Each diagram encodes the reasoning process; use them to structure thinking during the review board and to explain decisions to stakeholders.

Lookup vs Master-Detail

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

Figure 1. The two-master-detail limit per object is a hard platform constraint that changes the recommendation: when that limit is already reached but roll-ups are needed, the fallback is a Lookup relationship combined with DLRS or a Flow-based roll-up, accepting the operational overhead of a third-party or custom solution.

Key Factors Summary

Factor	Points to Master-Detail	Points to Lookup
Child meaningless without parent	Yes	No
Roll-up summaries needed	Yes (native)	No (need DLRS/Flow)
Sharing inheritance needed	Yes	No
Child needs its own owner	No	Yes
Field can be blank	Never	Sometimes
Cascade delete desired	Yes	No
Reparenting needed	Rarely	Often

---

Standard vs Custom Objects

Before creating a custom object, exhaust standard object options.

Figure 2. Name similarity alone is not sufficient justification for using a standard object. The key tests are whether built-in features add genuine value and whether forcing business data into the standard object would create a God Object or break AppExchange package assumptions.

Decision Criteria

Criterion	Standard Object	Custom Object
Built-in process support	Lead conversion, Opportunity stages, Case escalation	Must build from scratch
AppExchange compatibility	Most packages expect standard objects	May need custom mapping
User familiarity	Users know “Accounts” and “Contacts”	Requires training
Schema flexibility	Limited by existing fields	Full control
Governor limit implications	Some have higher limits	Standard limits

---

LDV Mitigation Approach

When a scenario presents an object with growing volume, the decision sequence matters. Start by identifying the query patterns — what list views, reports, and SOQL queries access this object, and which filter fields they use. Then evaluate whether those filter fields are indexed and whether they meet selectivity thresholds (30% for standard indexes, 10% for custom). If the object is wide (many fields) and queries need only a narrow subset, a skinny table is the right tool because it reduces row scan overhead independent of selectivity. If the object is approaching 10M records with sustained growth, an archival strategy must accompany the indexing work — indexes alone cannot solve volume growth without a ceiling. Common wrong answers: recommending skinny tables as a first-line response for any LDV problem (they are a narrow-object, high-field-count solution, not a general-purpose one), or proposing archival without addressing current-state query performance.

Archival Strategy Selection

The key evaluation criteria are access frequency, Salesforce-side query requirement, volume, and compliance. Data that users access daily should not be archived — optimize it with indexes. Data accessed occasionally but required to be queryable from within Salesforce (audit lookups, historical case data) fits Big Objects with Batch Apex query pipelines. Data accessed only for compliance retention can go to external storage with no Salesforce-side visibility. Data that needs analytics processing at scale (hundreds of millions of records) is a Data Cloud use case. The wrong answers candidates give: proposing Big Objects for data that will exceed a billion records without addressing that Big Object indexes are immutable at creation (schema changes require a Support case), or recommending external storage without a Salesforce Connect adapter when users need to see the data in Salesforce.

Archival Strategy

When data volume grows, choose the right archival approach.

Figure 3. Access frequency is the primary archival driver: daily-access data stays on-platform with optimization; monthly-access data routes to Big Objects or external storage based on volume; compliance-only data routes to the cheapest compliant store or is deleted once retention obligations are met.

---

Migration Cutover Strategy

Big Bang works when the total data volume can be loaded within the allowed downtime window (typically a weekend), the data model is relatively simple, and the business can absorb a clean break from the legacy system. Phased migration is the right call when volume exceeds the window, the data model has complex dependencies that make a full load risky, or business units can be moved incrementally. Parallel run is reserved for high-risk migrations where the business requires a live fallback — it doubles operational cost and requires dual data entry during the overlap period. Wrong answers: recommending Big Bang for a 200M-record migration without addressing that Bulk API 2.0 limits (100M records per 24-hour window) make a single-weekend load impossible at that volume, or recommending Parallel Run without acknowledging the data reconciliation burden it creates.

Migration Approach

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

Figure 4. Volume is an automatic decision gate: above 100M records, phased migration is mandatory regardless of business preference because no single cutover window is long enough. Below that threshold, downtime availability and source system count drive the strategy choice.

Strategy Quick Reference

Strategy	Best When	Risk Level	Cost
Big Bang	Small-medium volume, clear cutover window	High (all-or-nothing)	Low
Phased	Large volume, multiple objects/BUs	Medium (incremental)	Medium
Parallel Run	High risk, must validate before switch	Low (fallback available)	High

---

Person Accounts Decision

Person Accounts is an irreversible decision. Evaluate carefully.

Figure 5. The AppExchange compatibility audit is a hard prerequisite before enabling Person Accounts in an org with existing packages. A single incompatible managed package that cannot be patched can block the entire Person Accounts enablement, making the audit a go/no-go gate rather than an afterthought.

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.

Figure 6. Salesforce’s SOQL relationship query limits and governor constraints shift the normalization trade-off compared to traditional databases. High-volume objects with many fields and always-together query patterns can justify denormalization, but the risk of a data consistency bug in sync triggers must be weighed against the query performance gain.

Platform-Specific Normalization Factors

Factor	Favors Normalization	Favors Denormalization
SOQL relationship queries	5 levels child-to-parent; up to 5 levels parent-to-child in both Apex and REST API	Single object = simpler queries
Governor limits	Multiple DML = more limit consumption	Single DML = fewer limits
Sharing model	Each object has independent sharing	One sharing model for combined data
Field count	Spread across objects	Risk hitting 800 field limit
Reporting	Complex report types needed	Single object = simpler reports
Data volume	Each object can scale independently	One large table = LDV sooner
Maintenance	More objects to maintain	Fewer objects but larger

---

Data Virtualization vs ETL

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

Figure 7. Freshness and write access together determine the architecture. Real-time read-only data fits Salesforce Connect. Real-time read-write data requires two-way middleware sync. Near-real-time high-volume data with analytics requirements points to Data Cloud rather than replication into standard Salesforce objects.

Quick Reference

Approach	Freshness	Reporting	Write	Complexity	Cost
Salesforce Connect	Real-time	Limited	No	Low	Connect license
ETL Replication	Batch	Full	Via sync	Medium	ETL tool
2-Way Sync	Near real-time	Full	Yes	High	Middleware
Data Cloud	Near real-time	Advanced	Limited	Medium	Data Cloud license

---

MDM Pattern Selection

When Salesforce is unambiguously the system of record for customer data and the integration landscape is controlled, native Salesforce deduplication (matching rules + duplicate rules) combined with External ID-based upsert is sufficient. When multiple upstream systems all contribute customer records and none can be declared the single master, the coexistence or registry pattern is required — and Data Cloud identity resolution is the platform-native answer for B2C scenarios at scale. The wrong answer is treating this as a binary “Salesforce vs external MDM” choice. Real-world MDM decisions are about data ownership boundaries, not product preferences. Candidates who default to “Salesforce is the master” without examining what the ERP, CRM, or marketing system owns get pushed hard in Q&A.

How to Use These Guides on the CTA Exam

These decision flowcharts represent the structured thinking 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…”

---

Related Topics

• Sharing Model: lookup vs master-detail decision directly determines sharing inheritance
• Security Decision Guides: OWD and sharing strategy flowcharts complement data model decisions
• Integration Patterns: data virtualization vs ETL decision drives integration pattern selection
• Data Trade-offs: detailed trade-off analysis for each decision in these guides
• Org Strategy: Person Account and multi-org decisions affect org-level architecture
• Build vs Buy: standard vs custom object decision parallels build-vs-buy evaluation

Sources

• Salesforce Architects: Data 360 Architecture
• Salesforce Help: Object Relationships Overview
• Salesforce Help: Access External Data with Salesforce Connect
• Salesforce Help: Considerations for Using Person Accounts
• CTA Study Guide: Data Domain - Architecture Decisions
• Trailhead: Data Modeling