Best Practices & Anti-Patterns

System architecture best practices for the CTA exam are not academic ideals — they are patterns that consistently produce maintainable, scalable, and cost-effective solutions. Equally important is recognizing anti-patterns: common mistakes that seem reasonable but lead to architectural debt.

Platform-First Thinking

The most important principle for a Salesforce CTA: always start with what the platform provides before introducing external systems.

The Platform-First Decision Ladder

flowchart TD
    A[Requirement] --> B{Can it be solved<br/>with configuration?}
    B -->|Yes| C["Declarative Solution<br/>(Flows, Validation Rules,<br/>Formulas, Page Layouts)"]
    B -->|No| D{Can it be solved<br/>with standard Apex/LWC?}
    D -->|Yes| E["Custom Code<br/>(Apex, LWC, SOQL)"]
    D -->|No| F{Can async processing<br/>handle the constraint?}
    F -->|Yes| G["Async Apex<br/>(Batch, Queueable, Future)"]
    F -->|No| H{Can AppExchange<br/>solve it?}
    H -->|Yes| I["AppExchange Package<br/>(Evaluate carefully)"]
    H -->|No| J["Off-Platform Solution<br/>(Heroku, MuleSoft, Custom)"]

    style C fill:#2d6a4f,color:#fff
    style E fill:#457b9d,color:#fff
    style G fill:#457b9d,color:#fff
    style I fill:#e9c46a,color:#000
    style J fill:#9d0208,color:#fff

Why platform-first matters on the exam

CTA judges evaluate whether you leverage the platform appropriately. Going off-platform without justification signals a lack of platform knowledge. Going off-platform with clear justification (governor limits, processing requirements, user experience needs) signals mature architectural thinking.

Platform-First Does NOT Mean Platform-Only

Platform-first is a decision-making process, not a constraint. A good CTA knows when the platform is not the right tool:

Scenario	Platform-First Response
Need to process 100M records nightly	Batch Apex or external ETL — evaluate both
Need a consumer-facing mobile app with AR	Mobile SDK or fully custom app — Salesforce Mobile cannot do AR
Need real-time data streaming from IoT sensors	Platform Events have limits; consider Kafka or Kinesis
Need complex document rendering with dynamic charts	External document generation service — Salesforce PDF generation is limited

Well-Architected Framework Alignment

Salesforce’s Well-Architected Framework provides structured guidance across four pillars. CTA solutions should align with all four.

The Four Pillars

mindmap
    root((Well-Architected<br/>Framework))
        Trusted
            Security
            Compliance
            Reliability
            Performance
        Easy
            User Experience
            Accessibility
            Simplicity
            Self-Service
        Adaptable
            Scalability
            Extensibility
            Maintainability
            Evolution
        Connected
            Integration
            Data Flow
            API Strategy
            Ecosystem

Trusted

Principle: The solution must be secure, reliable, and compliant.

Practice	What It Means
Defense in depth	Multiple security layers (object, field, record, network)
Least privilege	Users get minimum access needed
Data classification	Know what data is sensitive and protect it accordingly
Monitoring	Proactive monitoring, not reactive firefighting
Compliance by design	Build compliance into the architecture, not bolt it on

Easy

Principle: The solution must be intuitive and reduce friction.

Practice	What It Means
User-centered design	Start with user workflows, not data models
Progressive disclosure	Show users what they need when they need it
Minimize clicks	Every click is friction; reduce unnecessary steps
Consistent experience	Same patterns across the application
Self-service	Users can find answers without opening support tickets

Adaptable

Principle: The solution must evolve without major rework.

Practice	What It Means
Modular design	Loosely coupled components that can change independently
Configuration over code	Prefer declarative when possible for easier change
Extensibility points	Design for future requirements without over-engineering
Technical debt awareness	Track and plan for refactoring
Upgrade-safe	Custom code and config that survive Salesforce releases

Connected

Principle: The solution must integrate effectively with the broader ecosystem.

Practice	What It Means
API-first	Design integrations around well-defined APIs
Event-driven	Use events for loose coupling between systems
Single source of truth	Each data element has one authoritative system
Idempotent operations	Integration operations can be safely retried
Error handling	Every integration point has error handling and monitoring

System Architecture Best Practices

Design Principles

Principle	Application
Single source of truth	Every data element is owned by exactly one system
Separation of concerns	UI, business logic, data access, and integration are separate layers
Fail gracefully	System continues to function (degraded) when a component fails
Design for bulk	Every piece of code must handle 200+ records per transaction
Minimize technical debt	Do not build temporary solutions that become permanent
Document decisions	Record why you chose X over Y (ADRs)
Test at every level	Unit, integration, UAT, regression, performance
Monitor proactively	Know about problems before users report them

Data Architecture Best Practices

Practice	Detail
Normalize the data model	Avoid redundant data unless denormalization is justified by performance
Plan for LDV from day one	If a table might exceed 1M records, design for it now
Use indexed fields in queries	SOQL queries on non-indexed fields perform poorly at scale
Avoid SOQL in loops	Bulkify all queries; query once, iterate on results
Use selective queries	WHERE clauses that filter out >90% of records
Archive old data	Big Objects, external storage, or data warehouses for historical data

Integration Best Practices

Practice	Detail
Idempotent operations	Ensure retrying an operation produces the same result
Circuit breaker pattern	Stop calling a failing service; retry after backoff
Error queue and replay	Capture failed messages for retry and investigation
Rate limiting awareness	Respect Salesforce API limits and external system rate limits
Async by default	Use async integration unless real-time is a hard requirement
Contract-first APIs	Define the API contract before building the implementation

Security Best Practices

Practice	Detail
Least privilege	Grant minimum permissions needed for each user
Never hard-code credentials	Use Named Credentials for callout authentication
Encrypt sensitive data	Use Shield Platform Encryption for PII and regulated data
Audit access	Enable Event Monitoring for login and data access forensics
SSO everywhere	Use SSO (SAML/OIDC) instead of Salesforce username/password
Regular reviews	Periodic review of user access, sharing rules, and permissions

Anti-Patterns

Architecture Anti-Patterns

Anti-Pattern	Problem	Correct Approach
Everything custom	Building custom what the platform provides natively	Evaluate standard features first
One giant org	Cramming unrelated businesses into one org	Evaluate multi-org when business units share nothing
Premature multi-org	Splitting without justification	Default to single-org; document multi-org rationale
Integration spaghetti	Point-to-point integrations without middleware	Hub-and-spoke or API-led connectivity pattern
Monolithic Apex	One massive Apex class doing everything	Separation of concerns (trigger handler, service, selector)
Click-to-code	Starting with code before evaluating declarative	Platform-first decision ladder
Gold plating	Over-engineering for hypothetical future needs	Design for current requirements with clear extension points

Data Anti-Patterns

Anti-Pattern	Problem	Correct Approach
SOQL in loops	Queries inside for-loops hit governor limits	Query once, use maps for lookups
Wide objects	Objects with 300+ fields	Split into related objects
Recursive triggers	Triggers firing in infinite loops	Static variable flags, trigger framework
Hard-coded IDs	Record type IDs, user IDs in code	Use Custom Metadata or Schema class
No data archival	Tables growing without bound	Archive strategy with Big Objects or external
Over-denormalization	Copying fields across objects to avoid queries	Accept the query cost; use formula fields

Integration Anti-Patterns

Anti-Pattern	Problem	Correct Approach
Synchronous callouts for batch data	Blocking user transactions on external calls	Async callouts, platform events, or batch processing
No error handling	Integrations that fail silently	Comprehensive error handling with monitoring
Tight coupling	External system changes break Salesforce	Middleware layer or adapter pattern
Polling for changes	Periodically querying for updates	CDC, Platform Events, or webhooks
Over-reliance on triggers for integration	Complex integration logic in trigger handlers	Dedicated integration layer

Licensing Anti-Patterns

Anti-Pattern	Problem	Correct Approach
Full CRM for everyone	Massive license overspend	Audit and right-size; Platform licenses for non-CRM users
Community Plus for simple portals	Paying for sharing model that is not needed	Customer Community if no role hierarchy required
Ignoring login-based pricing	Overpaying for infrequent external users	Model usage; switch to login-based below break-even
Edition upgrade for one feature	Paying Premium price for one capability	Evaluate add-on or PSL instead

Architectural Trade-Off Documentation

Every significant architectural decision should be documented with trade-offs explicitly stated. Use this template:

Decision Record Template

Decision: [What was decided]
Context: [Why this decision was needed]
Options Considered:
  1. [Option A] — [Pros] / [Cons]
  2. [Option B] — [Pros] / [Cons]
  3. [Option C] — [Pros] / [Cons]
Decision: [Which option was chosen]
Rationale: [Why this option was chosen over others]
Trade-offs Accepted: [What was given up]
Reversibility: [How hard is it to change this decision later]

CTA exam application

On the CTA exam, judges specifically ask: “What alternatives did you consider?” and “What trade-offs did you accept?” Having a mental model for documenting decisions helps you answer these questions fluently. Practice articulating trade-offs for every major decision in your mock boards.

Scalability Checklist

Before finalizing a system architecture, validate against this checklist:

Trade-Offs — Detailed trade-off analysis for each decision area
Decision Guides — Visual decision flowcharts
Platform Capabilities & Constraints — Governor limits and platform boundaries
Development Lifecycle — CI/CD, testing, and governance best practices

Sources

Salesforce Architects: Well-Architected Framework
Salesforce Architects: Trusted Pillar
Salesforce Architects: Easy Pillar
Salesforce Architects: Adaptable Pillar
Salesforce Architects: Architecture Decision Records
Salesforce Developer Docs: Apex Best Practices
Salesforce Developer Docs: Trigger Bulkification
Salesforce Trailhead: Well-Architected Trail