Trade-Offs
Every system architecture decision involves trade-offs. The CTA exam specifically tests your ability to identify, articulate, and defend these trade-offs. This page consolidates the major trade-off dimensions across Domain 1.
How judges evaluate trade-offs
CTA judges do not expect a “perfect” answer. They expect you to demonstrate that you understand what you are giving up with every choice. Saying “I chose X because of benefit A, and I accept the trade-off of limitation B, which I mitigate by doing C” is significantly 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 must make a judgment call and defend 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 but has hidden costs:
flowchart TD
subgraph "Visible Costs"
A[Development]
B[Infrastructure]
end
subgraph "Hidden Costs (below the waterline)"
C[Security implementation]
D[Monitoring and alerting]
E[Backup and disaster recovery]
F[OS and runtime patching]
G[Integration maintenance]
H[Performance tuning]
I[Compliance auditing]
J[Team training]
end
A --> C
B --> D
C --> E
D --> F
E --> G
F --> H
G --> I
H --> J
The 5x rule
A common industry heuristic: the ongoing maintenance cost of an off-platform solution is 3-5x the initial development cost over a 5-year period. Factor this into TCO calculations when recommending off-platform. On-platform solutions have significantly lower ongoing costs 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
When evaluating whether to buy from AppExchange:
| 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
quadrantChart
title License Strategy Trade-offs
x-axis Low Cost --> High Cost
y-axis Low Friction --> High Friction
"Full CRM for all": [0.85, 0.15]
"Right-sized per user": [0.35, 0.65]
"Over-optimized (too many types)": [0.15, 0.9]
"Platform + CRM mix": [0.5, 0.4]
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 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 or Tableau unless standard reports cannot meet the requirement. Common escalation triggers:
- Need to join more than 4 objects
- Need historical trending beyond 3 months
- Need predictive analytics
- Need to combine Salesforce + external data
- Need complex calculations beyond formula capabilities
- 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
Use this framework to structure trade-off analysis for any decision on 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
The trade-off analysis framework is a skill that improves with practice. Apply it to every mock board scenario. After enough repetitions, it becomes second nature — which is exactly what you need 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