Skip to content
theCodeFlash

Integration

Key Takeaways

Integration is the highest-failure domain on the CTA exam. Know all 6 official Salesforce integration patterns, when middleware (MuleSoft) is justified vs point-to-point, event-driven architecture options, error handling strategies, and how to defend pattern choices with clear trade-off analysis. Always show the middleware layer in diagrams.

Designing enterprise integrations, selecting technologies, and justifying patterns. Integration fails more candidates than any other domain. Passing requires knowing not just what the patterns are, but why and when to apply each one.

Study Content

Patterns & Architecture

  • Integration Patterns: All 6 official Salesforce integration patterns with sequence diagrams, selection criteria, and timing
  • Middleware Architecture: MuleSoft API-led connectivity, ESB vs iPaaS, middleware justification vs point-to-point
  • Event-Driven Architecture: Platform Events vs CDC vs Streaming vs Pub/Sub, event bus architecture, replay

Technology & Implementation

Decision & Strategy

  • Integration Decision Guides: 9 decision trees as Mermaid flowcharts covering sync vs async, middleware vs P2P, which API to use, and more
  • Best Practices: Design, implementation, testing, and operations best practices with anti-patterns section
  • Integration Trade-offs: Common trade-offs for CTA scenarios with structured analysis framework

Objectives

  • Recommend enterprise integration options; describe risks, trade-offs, and business/technical considerations
  • Describe capabilities of appropriate technology and justify use in overall integration architecture
  • Recommend and justify appropriate integration strategy and common integration patterns
  • Recommend platform-specific integration technology for external systems

Practice

Key Exam Focus Areas

The CTA review board probes Domain 5 with specific, operational questions. Vague answers cost marks. The following areas are the most frequently tested and carry the highest failure risk.

  • Pattern justification per touchpoint: The board expects you to name the pattern for each integration, defend it against the alternatives, and explain the timing choice (real-time vs near-real-time vs batch). A common failing answer is choosing near-real-time for every touchpoint without per-scenario justification.
  • MuleSoft vs point-to-point threshold: The trigger for middleware is 3+ systems, complex transformation chains, or centralized governance requirements. Two systems with no growth plan do not justify MuleSoft’s cost and complexity. Know the hybrid answer: direct for simple stable integrations, middleware for multi-system and orchestrated flows.
  • Platform Events vs CDC vs Pub/Sub API selection: Platform Events suit custom-defined business events with schema you control. CDC suits automatic change notifications for any record change on an enabled object. Pub/Sub API suits high-throughput external subscribers that need managed subscriptions over gRPC. Conflating these three is a common failure.
  • Bulk API 2.0 volume thresholds: The board expects specific numbers. REST API below roughly 2,000 records per operation. Bulk API 2.0 serial mode from 2K to 100K. Bulk API 2.0 parallel mode from 100K to 10M. Above 10M, add job partitioning and off-peak scheduling. Using REST API for bulk data loads is a trap the board specifically tests.
  • Error handling completeness: Every integration must have a retry strategy (exponential backoff with jitter for transient errors), idempotency design (at-least-once delivery means duplicates will occur), a dead letter queue (nothing is silently dropped), circuit breaker for systemic failures, and monitoring. Saying “we retry” without specifics on count, backoff formula, and fallback behavior loses marks.
  • API limit planning: Estimate daily API call consumption across all integrations and compare against the org allocation. The concurrent long-running call limit of 25 is the most overlooked limit. Design with headroom, not at capacity.
  • GraphQL mutations GA status: GraphQL mutations became generally available in API v66.0 (Spring ‘26). Recommending GraphQL for mutations in a current scenario is now architecturally sound; it was beta before Spring ‘26.
  • Heroku Connect lifecycle awareness: Heroku Enterprise entered end-of-sale in February 2026. The board will accept Heroku Connect for existing deployment scenarios, but expects cloud-native alternatives (AWS RDS + MuleSoft, GCP Cloud SQL) for new greenfield designs. Never recommend Heroku for new architecture.

Integration touches nearly every other domain. These connections matter most:

  • Security Architecture — OAuth 2.0 flow selection (JWT Bearer for server-to-server, Client Credentials for machine-to-machine) and Named Credentials design are integration-security decisions. Connected App governance for Remote Call-In patterns — which OAuth flow, token refresh strategy, and scope restrictions — lives at this domain boundary.
  • Data Architecture — Bulk API 2.0 is the primary vehicle for large-volume data migration. Change Data Capture bridges data and integration: when an external system needs a synchronized copy of Salesforce data, CDC is the architectural answer. Data Virtualization (Salesforce Connect) avoids migration entirely when LDV or regulatory constraints prohibit copying.
  • Solution Architecture — The integration boundary definition (what processes run in Salesforce vs in external systems) is a solution architecture decision that determines integration surface area and pattern selection. Build vs buy for middleware platforms (MuleSoft vs Boomi vs custom ETL) is the primary solution architecture concern in integration-heavy scenarios.
  • Development Lifecycle — API versioning strategy (which API versions to support, deprecation policy, consumer notification process) is a lifecycle concern. Connected Apps, Named Credentials, and Remote Site Settings require structured deployment pipelines. Integration testing requires mock external endpoints in CI environments to avoid dependency on external system availability during builds.

Frequently Asked Questions

What integration topics does the CTA exam focus on most heavily?

All 6 official Salesforce integration patterns (Request-Reply, Fire-and-Forget, Batch, Remote Call-In, UI Update, Data Virtualization), middleware architecture (MuleSoft API-led connectivity, ESB vs iPaaS), event-driven architecture (Platform Events, CDC, Pub/Sub API), error handling strategies, and the Salesforce API surface including rate limits and authentication flows.

How is Integration scored in the CTA review board?

Judges check whether you selected the correct integration pattern for each system interaction, justified middleware vs point-to-point decisions, built a thorough error handling strategy (retry, circuit breaker, dead letter queue, idempotency), and drew integration diagrams that clearly show system boundaries, protocols, and data flow direction. Always include the middleware/ESB layer in diagrams.

What are the most common mistakes in Integration during the CTA exam?

Common failures: using synchronous patterns where asynchronous fits better, omitting middleware from integration diagrams, ignoring error handling and retry strategies, picking the wrong API type for the data volume (REST API for bulk operations instead of Bulk API 2.0), and not addressing rate limiting or API call budget consumption across all integrations.

When should I recommend MuleSoft middleware vs point-to-point integration?

MuleSoft middleware fits when the scenario has 3+ external systems, needs API reuse across multiple consumers, requires protocol transformation (SOAP to REST, XML to JSON), calls for centralized error handling and monitoring, or involves complex orchestration logic. Point-to-point works fine for simple, single-system integrations with low volume and straightforward data mapping.

How should I handle event-driven architecture questions at the review board?

Distinguish clearly between Platform Events (custom publish/subscribe), Change Data Capture (automatic change notifications), and Pub/Sub API (high-volume external subscription). Cover replay mechanisms for message recovery, event bus delivery guarantees, subscriber capacity, and when to pick each option. Platform Events suit custom business events; CDC suits data synchronization; Pub/Sub API suits external high-throughput consumers.

What error handling patterns should I include in my CTA solution?

Every integration needs a retry strategy (exponential backoff with jitter), idempotency (unique transaction IDs), circuit breaker for failing endpoints, dead letter queues for unrecoverable messages, monitoring and alerting, and reconciliation processes for data consistency verification. Judges look for thorough error handling specifically. Omitting it is a common failure point.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.