Best Practices & Anti-Patterns

These are not academic ideals. They are patterns that consistently produce maintainable, scalable, and cost-effective solutions. Recognizing anti-patterns matters just as much: common mistakes that seem reasonable but create architectural debt.

Platform-First Thinking

Always start with what the platform provides before introducing external systems. This is the single most important principle for a Salesforce CTA.

The Platform-First Decision Ladder

Figure 1. The platform-first decision ladder forces each requirement through five tiers before reaching an off-platform recommendation. CTA judges look for this escalation logic. Skipping directly to custom code or external systems without exhausting declarative and async options signals weak platform knowledge.

Why platform-first matters on the exam

CTA judges evaluate whether you use 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 also knows when the platform is the wrong 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 organizes guidance into three pillars. CTA solutions should align with all three.

The Three Pillars

Figure 2. The Salesforce Well-Architected Framework organizes solution quality into three pillars: Trusted (secure, compliant, reliable), Easy (intentional, automated, engaging), and Adaptable (resilient, composable). CTA solutions are evaluated against all three pillars simultaneously.

Trusted

Principle: The solution must be secure, compliant, and reliable. Secure solutions control access and protect data. Compliant solutions follow legal and ethical guidelines. Reliable solutions operate efficiently and dependably.

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 intentional, automated, and engaging. Intentional solutions deliver business value right away and over time. Automated solutions let the business get work done faster and at scale. Engaging solutions drive adoption.

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 be resilient and composable. Resilient solutions handle change well. Composable solutions adjust quickly and with greater stability.

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

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	Full 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 stated explicitly. 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

Judges specifically ask: “What alternatives did you consider?” and “What trade-offs did you accept?” A mental model for documenting decisions helps answer these questions under pressure. Practice articulating trade-offs for every major decision in mock boards.

Scalability Checklist

Before finalizing any system architecture, run through this checklist:

• Data model handles 10x current volume without redesign
• Integrations have error handling, retry logic, and monitoring
• Governor limits are not exceeded under peak load
• Reporting strategy scales with data volume growth
• Mobile strategy handles poor connectivity gracefully
• License model accommodates projected user growth
• Security model does not require per-user manual configuration
• Deployment strategy supports team growth (more developers)
• Archival strategy prevents unbounded table growth
• Monitoring enables proactive issue detection

Related Topics

• 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