Trade-Offs

Every system architecture decision involves trade-offs. The CTA exam specifically tests the ability to identify, articulate, and defend those trade-offs. This page consolidates the major trade-off dimensions across Domain 1.

How judges evaluate trade-offs

Judges do not expect a perfect answer. They expect a demonstration that the trade-offs of each choice are understood. “I chose X because of benefit A, and I accept the trade-off of limitation B, which I mitigate by doing C” is far stronger than “I chose X because it is the best option.”

Single-Org vs Multi-Org

Dimension	Single-Org	Multi-Org
Data visibility	Full 360-degree view natively	Requires integration for cross-org visibility
Cost	One license set, one admin team	Multiple license sets, multiple admin teams
Governance	One release cycle, one metadata set	Independent release cycles (flexibility)
Complexity	Lower baseline complexity	Higher baseline complexity
Security boundary	Sharing model within one org	Hard isolation between orgs
Scalability	Shares one org’s governor limits	Each org gets full governor limit allocation
Reporting	Native cross-functional reporting	Requires ETL or unified analytics layer
Identity	Single SSO integration point	SSO to each org (or identity hub)
Risk	Single point of failure (one org)	Blast radius contained to affected org
Customization conflict	All teams share same metadata	Teams can customize independently

When Each Side Wins

Single-org wins when: Business units share customers, sales teams collaborate across units, executives need unified reporting, or total cost matters.

Multi-org wins when: Regulatory isolation is mandatory, business units are truly independent, release cadence conflicts are irreconcilable, or security boundaries must be absolute.

The gray zone: Most real-world scenarios are not clearly one or the other. The CTA makes a judgment call and defends it. There is rarely a definitively “right” answer, only a well-reasoned one.

---

On-Platform vs Off-Platform

Dimension	On-Platform	Off-Platform
Maintenance	Salesforce handles infrastructure, upgrades	Your team manages infrastructure, patching
Speed to market	Fast (declarative + Apex)	Slower (full SDLC)
Cost model	Included in license (mostly)	Separate infrastructure + development cost
Governor limits	Bounded by platform limits	No artificial limits (only hardware)
Security	Inherited from Salesforce platform	Must implement your own security
Upgrades	Automatic (3 releases/year)	Manual; you own the upgrade cycle
Scalability	Automatic (within limits)	Manual (but uncapped)
Customization	Constrained to platform capabilities	Unlimited flexibility
Talent	Salesforce ecosystem talent pool	Broader developer talent pool
Integration	Native to Salesforce data	Requires API integration to Salesforce

The Cost Iceberg

Going off-platform looks simple at first. The hidden costs are substantial:

Figure 1. The off-platform cost iceberg shows that development and infrastructure are the only costs visible at decision time. Security implementation, monitoring, patching, compliance auditing, and ongoing integration maintenance accumulate below the waterline, typically running 3–5x initial development cost over five years.

The 5x rule

A common industry heuristic: ongoing maintenance for an off-platform solution runs 3-5x the initial development cost over a 5-year period. Factor this into TCO calculations when recommending off-platform. On-platform solutions cost far less to maintain because Salesforce absorbs infrastructure, security, and upgrade responsibilities.

---

Build vs Buy (AppExchange)

Dimension	Custom Build	AppExchange Package
Fit	Exactly matches requirements	May require compromise or workarounds
Time to value	Weeks to months of development	Days to weeks to deploy
Cost (initial)	Development cost	License cost
Cost (ongoing)	Maintenance, bugs, enhancements by your team	Vendor handles maintenance and updates
Dependency	You own the code; no vendor lock-in	Vendor dependency; risk of EOL or acquisition
Upgradability	Your responsibility to align with SF releases	Vendor ensures compatibility (ideally)
Support	Your team supports it	Vendor provides support
IP ownership	You own the IP	Vendor owns the IP
Limit consumption	Controllable	May consume governor limits unpredictably
Security review	You control access patterns	Must trust vendor’s security model

AppExchange Evaluation Criteria

Evaluation criteria for AppExchange packages:

Criterion	What to Check
Security review	Is the package Salesforce Security Reviewed?
Limit consumption	Does the package consume SOQL queries, DML, or API calls? How many?
Data model impact	Does it create custom objects that interact with your data model?
Upgrade path	How often is it updated? What happens during Salesforce releases?
Uninstall risk	Can you cleanly uninstall? What data and metadata is left behind?
Vendor viability	Is the vendor financially stable? What if they are acquired or shut down?
Total cost of ownership	License cost + integration cost + customization cost + training cost

---

License Optimization Trade-Offs

Dimension	Fewer, Higher-Tier Licenses	More, Lower-Tier Licenses
Simplicity	Fewer license types to manage	More complex license assignment
Cost	Higher per-user cost	Lower per-user cost
Feature access	All users have full feature access	Users may hit feature walls
Admin overhead	Simple: everyone gets the same thing	Complex: auditing who needs what
Flexibility	Users can do anything	Users are constrained by license
Over-provisioning risk	High (paying for unused features)	Low (only paying for what is used)
Support friction	Low (no “I can’t access this” tickets)	Higher (users may need upgrades)

The Right-Sizing Balance

Figure 2. License strategy plotted on cost versus friction axes. The sweet spot is a Platform plus CRM mix (moderate cost, moderate friction) rather than the extremes of giving everyone full CRM (overspend) or over-optimizing with too many license types (admin complexity and user friction).

The sweet spot is typically 2-3 license types that cover 90% of users, with exceptions for edge cases.

---

Mobile: Native vs Hybrid vs PWA

Dimension	Native (SDK)	Hybrid (React Native)	PWA
Performance	Best	Good	Acceptable
Offline	Full (SmartStore)	Full (with libraries)	Limited (Service Worker)
Device APIs	Full native access	Most via plugins	Limited (browser APIs)
Development cost	Highest (per platform)	Medium (cross-platform)	Lowest
Maintenance cost	Highest (OS updates per platform)	Medium	Lowest
Deployment	App store review (days)	App store review (days)	Instant (web deploy)
Discoverability	App store search	App store search	Web search / link
Branding	Full control	Full control	Limited (browser chrome)
Team skills	Swift / Kotlin specialists	JavaScript / React	Web developers
Update frequency	App store limits rapid updates	App store limits rapid updates	Deploy as often as needed

When Each Wins

Native SDK: Mission-critical offline workflows with complex sync, deep device integration (Bluetooth, NFC, AR), or performance-critical applications.

Hybrid (React Native): Cross-platform needs with good offline, when the team has JavaScript skills, and when a single codebase for iOS+Android is more important than maximum performance.

PWA: Content-heavy portals, rapid iteration needs, budget constraints, or when users should not have to install an app.

---

Reporting: Standard vs CRM Analytics (formerly Tableau CRM) vs Tableau

Dimension	Standard Reports	CRM Analytics	Tableau
Cost	Included	Add-on license	Separate product
Setup time	Minutes	Days-Weeks	Weeks-Months
Learning curve	Low	Medium	Medium-High
Data sources	Salesforce only	SF + limited external	Any
Refresh	Real-time query	Scheduled dataflow	Live or extract
Complexity	Basic aggregations	Advanced analytics	Enterprise BI
Users	Business users	Analysts + users	Data teams + users
Embedding	Native	Native in SF	Requires Tableau Embedded
Predictive	No	Einstein Discovery	Tableau AI
Administration	Salesforce admin	CRM Analytics admin	Tableau admin team

The Escalation Principle

Do not recommend CRM Analytics (formerly Tableau CRM) or Tableau unless standard reports fall short. Common escalation triggers:

1. Need to join more than 4 objects
2. Need historical trending beyond 3 months
3. Need predictive analytics
4. Need to combine Salesforce + external data
5. Need complex calculations beyond formula capabilities
6. Need to serve non-Salesforce users

---

Document Management: Native vs External

Dimension	Salesforce Files	External DMS (SharePoint/Box)
Cost	Included (within limits)	Separate license
Integration	Native	Requires Files Connect or custom
Collaboration	Limited (Chatter comments)	Full co-authoring
Version control	Basic	Advanced
Compliance	Shield (add-on)	DLP, retention, legal hold
Access model	Follows SF sharing	Separate permission model
Storage capacity	Edition-dependent	Typically much larger
Offline sync	Limited	Desktop sync apps
Search	Full-text (on SF files)	Advanced search + metadata
User experience	In Salesforce	Context switch (or Files Connect)

---

Trade-Off Analysis Framework

A framework for structuring trade-off analysis on any decision during the CTA exam:

Step 1: Identify the Decision

What are you choosing between?

Step 2: List the Evaluation Dimensions

What factors matter for this decision? (Cost, complexity, performance, security, UX, maintainability, scalability, time-to-market)

Step 3: Score Each Option

For each dimension, which option wins? Is it a clear winner or a marginal difference?

Step 4: Identify the Deciding Factor

Which dimension is most important for this specific scenario? The deciding factor should come from the scenario requirements, not from general preference.

Step 5: Articulate What You Are Giving Up

State explicitly: “By choosing X, we accept trade-off Y. We mitigate this by doing Z.”

Practice this framework

Trade-off analysis improves with repetition. Apply this framework to every mock board scenario. The goal is to reach the point where identifying dimensions, deciding factors, and accepted trade-offs is immediate - not labored - when judges ask “Why did you choose that approach?” under pressure.

Related Topics

• Decision Guides: Visual decision flowcharts for each trade-off area
• Best Practices: Principles that guide trade-off decisions
• Org Strategy: Single vs multi-org trade-offs in depth
• Platform Capabilities & Constraints: Platform boundaries that drive off-platform decisions
• Review Board Presentation: How to present and defend trade-offs

Sources

• Salesforce Architects: Well-Architected Framework
• Salesforce Architects: Decision Guides
• Salesforce Architects: Architecture Tradeoffs
• Martin Fowler: Architectural Decision Records
• ThoughtWorks: Technology Radar - Industry context for build vs buy