Domain Grilling: D5 Integration
Integration is the highest-failure domain on the CTA exam. Judges expect candidates to name the exact pattern, justify it against alternatives, address error handling, and explain the timing. Vague answers like “we will use an API” or “we will integrate with middleware” lose points immediately.
Type 1: Invalid - “Your Solution Won’t Work”
The judge believes your approach is technically incorrect or impossible.
Q1.1: Pattern selection under volume constraints
Judge: “Your design shows a synchronous REST callout from Salesforce to the ERP for order creation. The scenario states orders average 15,000 per hour during peak. That synchronous pattern will not work at this volume. How do you address this?”
What they’re testing: Whether the candidate understands that synchronous Request-Reply breaks down under high volume due to governor limits (10s default timeout, 120s cumulative), concurrent API limits (25 long-running calls org-wide), and UX degradation.
Model answer: “You are right. At 15,000 orders per hour, synchronous callouts would saturate the concurrent call limit of 25 long-running requests. The correct pattern is Fire-and-Forget using high-volume Platform Events. The order saves, a PE fires with the payload, and MuleSoft subscribes via Pub/Sub API to route to the ERP asynchronously. The user gets immediate confirmation. Trade-off: eventual consistency. Error handling: MuleSoft implements retry with exponential backoff, DLQ for exhausted retries, and a reconciliation job every 4 hours to catch missed events beyond the 72-hour retention window. Keep Request-Reply only for touchpoints where the user genuinely cannot proceed without an answer.”
Follow-up: “What happens if MuleSoft itself goes down during peak and Platform Events approach their 72-hour retention limit?”
Q1.2: External Objects limitations
Judge: “Your integration architecture uses External Objects via Salesforce Connect to display ERP product data. You also mentioned running approval processes and Apex triggers on those External Objects. That will not work. What are you actually going to do?”
What they’re testing: Whether the candidate knows the hard limitations of External Objects: no Apex triggers, no approval processes, no Process Builder, limited Flow support, limited reporting.
Model answer: “You are correct. External Objects cannot participate in Apex triggers, approval processes, or standard automation. I would redesign as a hybrid. For display purposes, External Objects remain correct: the catalog is large, changes frequently in the ERP, and the business only needs to view it. For the subset requiring Salesforce automation, I would replicate those records into a native custom object using nightly Bulk API 2.0 batch sync. The replication scope stays narrow: only products in an active deal pipeline, not the full 500,000-item catalog. Trade-off: maintaining two data paths, but it keeps storage low while enabling full platform functionality where needed.”
Follow-up: “How would you handle the scenario where a user is viewing an External Object product record and needs to initiate an approval?”
Q1.3: Synchronous callout timeout constraints
Judge: “Your integration diagram shows a synchronous callout to the shipping provider during record save. The shipping API averages 8 seconds with spikes to 30 seconds. That will blow past the Apex callout timeout and block the user. How do you fix this?”
What they’re testing: Whether the candidate understands Apex callout governor limits (10s default, 120s max, 120s cumulative) and UX implications of synchronous blocking during record save.
Model answer: “An 8-second average with 30-second spikes means the callout will time out on the default 10-second limit, and even extended to 120s, blocking users for 8-30 seconds is unacceptable UX. I would move to async: record saves immediately, a Queueable Apex job fires the callout without blocking the user. The shipping response writes back when it arrives. An LWC on the record page subscribes to a PE for the shipping confirmation. Error handling: max 3 retries, failures route to Integration_Error__c. Trade-off: user does not see shipping confirmation instantly, but a ‘Shipping status pending’ message resolving in seconds is better than an 8-30 second spinner.”
Follow-up: “What if the business insists the shipping label must be generated before the warehouse team can proceed?”
Q1.4: Bulk API lock contention
Judge: “You are loading 2 million Account records with child Contacts using Bulk API 2.0 in parallel mode. Testing shows frequent UNABLE_TO_LOCK_ROW errors. What went wrong and how do you fix it?”
What they’re testing: Whether the candidate understands serial vs parallel processing modes and lock contention with parent-child data.
Model answer: “Parallel mode processes concurrent batches. When two batches insert Contacts for the same parent Account simultaneously, they compete for the row lock. Fix: split into two sequential jobs. Load Accounts first in parallel (no shared locks). Load Contacts in a second job using serial mode to eliminate cross-batch contention. Trade-off: serial is 3-5x slower. Schedule during off-peak. Sort the Contact CSV by AccountId so siblings cluster in the same batch. For 2M records across a weekend, the longer runtime is acceptable. If speed is critical, partition the Contact file by Account ID ranges, running multiple serial jobs on non-overlapping parent sets.”
Follow-up: “How does this strategy change when adding Opportunities and OpportunityLineItems?”
Q1.5: CDC vs Platform Events for business events
Judge: “You are using CDC to notify the billing system when an Order is submitted, Invoice generated, and Payment received. CDC fires per-object, not per-business-event. How do you handle that?”
What they’re testing: Whether the candidate understands CDC publishes per-object change events, not composite business events requiring Platform Events with custom schema.
Model answer: “CDC fires independently on each object — three separate, uncoordinated events. The subscriber would have to correlate using transactionKey. The right tool is a custom Platform Event (Order_Fulfillment__e) with fields for all three IDs, status, and a correlation ID. Publish logic fires from Apex only when all three conditions are met using a state machine or Flow. Subscribers receive one coherent event. Keep CDC for data replication where knowing exactly which fields changed is the point. Trade-off: custom publish logic vs CDC’s automatic firing, but semantic correctness is worth the additional code.”
Follow-up: “What happens if the Payment record is created in a separate transaction from the Invoice and your trigger misses the timing window?”
Q1.6: Outbound Message limitations
Judge: “Your design uses Outbound Messages to notify three different external systems when a Case is escalated. Outbound Messages deliver to a single SOAP endpoint. How are you reaching three subscribers?”
What they’re testing: Whether the candidate knows Outbound Messages push to a single endpoint and cannot fan out natively.
Model answer: “An Outbound Message delivers to exactly one SOAP endpoint. The correct approach is Platform Events: define a Case_Escalation__e event, publish from a Flow when escalation criteria are met. Each external system subscribes independently via Pub/Sub API, managing its own replay position and processing at its own pace. For a legacy subscriber that cannot adopt Pub/Sub, middleware subscribes to the PE and transforms the payload into a SOAP call. Trade-off: losing the built-in 24-hour retry of Outbound Messages, but gaining multi-subscriber fan-out, replay capability, and modern protocol.”
Follow-up: “One of those three systems is an on-premise mainframe that can only accept files via SFTP. How does that change your approach?”
Type 2: Missed - “You Haven’t Addressed…”
The judge is pointing out a gap in your architecture.
Q2.1: Error handling strategy
Judge: “Your integration architecture shows five touchpoints, all with happy-path flows. I do not see any error handling strategy. What happens when the ERP is down for two hours during business hours?”
What they’re testing: Error handling is the most commonly missed element. The board expects retry, circuit breaker, DLQ, monitoring, and recovery for every touchpoint.
Model answer: “Every touchpoint should have a defined error handling stack. For the ERP: (1) Retry with exponential backoff (1s, 2s, 4s) plus jitter for transient errors. (2) Circuit breaker after 5 consecutive failures — fail fast without hitting the ERP. After 60s, half-open probe tests recovery. (3) DLQ (Integration_Error__c) with original payload, error details, retry count, correlation ID. (4) Monitoring dashboard + PagerDuty alerts when circuit opens or DLQ depth exceeds 100. (5) Recovery: bulk resubmission from DLQ in sequence. For a 2-hour outage, zero data loss. Apply this pattern to all five touchpoints, calibrated per touchpoint: address validation gets graceful degradation to cached data instead of a DLQ.”
Follow-up: “How do you prevent the bulk DLQ replay from overwhelming the ERP the moment it comes back online?”
Q2.2: Idempotency for event replay
Judge: “Your Platform Event design for order notifications delivers at-least-once. I do not see any idempotency strategy. What prevents duplicate order processing when events replay?”
What they’re testing: At-least-once delivery guarantees mean duplicates will occur; the consumer must be idempotent.
Model answer: “At-least-once means the warehouse will occasionally receive the same event twice. Without idempotency, duplicate orders are created. Implement at two levels. First, the PE payload includes the Salesforce Order record ID as a natural unique key. The warehouse checks this against its processed-orders table before creating anything. Second, on the Salesforce side, callback updates use upsert with the Order external ID. For middleware, add an idempotency filter caching recently processed event replay IDs in Object Store with a TTL matching the 72-hour PE retention. Events with a seen replay ID are acknowledged and discarded. Trade-off: small lookup overhead per event, negligible at this volume.”
Follow-up: “What happens if the idempotency store itself fails or loses state during a restart?”
Q2.3: API budget calculation
Judge: “You have eight integration touchpoints consuming API calls but no API budget analysis. Have you calculated whether this org can handle the total daily consumption?”
What they’re testing: Whether the candidate can articulate the allocation formula, per-integration consumption estimate, and headroom strategy.
Model answer: “The org is on Unlimited Edition with 500 users. Allocation: 100,000 base + (500 x 5,000) = 2,600,000 daily. ERP sync: 5,000 orders x 3 calls = 15,000. Billing: 2,000 invoices = 6,000. DW nightly batch (Bulk API): ~10 calls. Portal: 20,000 queries. Address validation: 8,000 calls. Marketing sync, monitoring, metadata: ~10,000. Total: ~59,000 at 2.3% utilization. Comfortable headroom, but I would still implement monitoring at 80% (warning) and 95% (critical). Composite API consolidation on the ERP (3 calls to 1) would cut that touchpoint 60%. If approaching limits, prioritize customer-facing integrations, defer batch to off-peak.”
Follow-up: “The client acquires another company, doubling all integration volumes. Does your API budget still hold?”
Q2.4: Authentication strategy
Judge: “Six external systems call into Salesforce but I see no authentication strategy. How are these systems authenticating?”
What they’re testing: OAuth flow strategy per integration, Named Credentials, Connected Apps, and least-privilege principles.
Model answer: “Four server-to-server integrations (ERP, billing, DW, inventory): JWT Bearer flow. Each gets a dedicated External Client App (ECA) with scoped permissions. Starting Spring ‘26, new Connected App creation is disabled by default for new orgs, and Salesforce directs all new integrations to External Client Apps as the successor framework — ECAs carry forward the OAuth and security model while adding distribution and lifecycle improvements. Existing Connected Apps continue to function, so only brand-new integrations default to ECA. JWT uses X.509 certificates — more secure than client credentials for S2S. Customer portal (user context): OAuth Authorization Code with PKCE. Mobile field service: same Auth Code + PKCE. All outbound Salesforce callouts use Named Credentials. Never store credentials in Custom Settings, Metadata, or Apex. Each ECA has IP restrictions, a dedicated non-admin integration user with minimal Permission Sets, and refresh token rotation. Credential rotation on 90-day cycle with 30-day expiration alerts.”
Follow-up: “What happens if the ERP team rotates their certificate without coordinating?”
Q2.5: Data migration as integration
Judge: “The scenario mentions migrating 8 million records from a legacy CRM. I do not see a data migration strategy. How do you handle that?”
What they’re testing: Whether the candidate treats data migration as an integration problem with its own pattern selection, sequencing, error handling, and reconciliation.
Model answer: “For 8M records: Bulk API 2.0 through middleware with defined sequence and reconciliation. Sequencing: reference data and parents first (Accounts), then Contacts, Opportunities, then Activities/Notes. External IDs on every object enable relationship mapping. Load: serial mode for parent-child pairs to avoid locks, parallel for independents. Partition into 500K-record jobs during off-peak across a 2-week window. Transformation in MuleSoft before data enters Salesforce. Reconciliation: count comparison, 1% sample field audit, relationship integrity check after each object. Failed records to staging table for review. Rollback: maintain External ID mapping file for purge-and-reload of specific batches.”
Follow-up: “The legacy CRM has 300,000 duplicate Contact records. How do you handle deduplication?”
Q2.6: Integration testing strategy
Judge: “You have not mentioned how you would test these integrations. What is your integration testing strategy?”
What they’re testing: Multi-layer testing approach: unit, contract, integration, end-to-end, and failure simulation.
Model answer: “Four layers. (1) Unit tests with HttpCalloutMock/StaticResourceCalloutMock: simulate success, error (400, 500, 503), timeout, malformed payloads. Target 90% coverage on integration Apex, specific tests for error paths. (2) Contract tests: validate request/response schemas against the external API’s OpenAPI/WSDL. Catches schema drift before deployment. (3) End-to-end in a dedicated integration sandbox connected to external test environments. Fire PEs, verify they arrive in MuleSoft, confirm transformed payload reaches external system, validate callback updates. (4) Failure simulation: 503s from mock endpoints to test circuit breakers, duplicate events for idempotency, 2x peak volume for governor limits. CI/CD: unit + contract on every commit (scratch org). E2E nightly (integration sandbox). Failure simulation weekly.”
Follow-up: “How do you handle Connected App credentials differing between sandbox and production in CI/CD?”
Type 3: Suboptimal - “Have You Considered…?”
The judge is suggesting a better approach exists.
Q3.1: Middleware overkill
Judge: “You recommend MuleSoft for a single integration between Salesforce and a payment gateway. The client has 200 users and no other integration needs on the roadmap. Have you considered whether that middleware is justified?”
What they’re testing: Whether the candidate can recognize when middleware is overkill and direct point-to-point is better.
Model answer: “Middleware-or-not is always a ‘depends’ question, and the criteria I evaluate are: number of integrated systems, transformation complexity, orchestration needs, reusability, centralized governance requirements, error-handling patterns, and roadmap. For this scenario — a single, stable two-system integration, no orchestration, no multi-format transformation, no roadmap for growth — middleware is not justified. Direct Apex callout with Named Credentials: the payment gateway exposes REST, a small Apex class handles the callout, Named Credentials manage auth/refresh. Error handling uses a lightweight retry pattern with Integration_Error__c for failures. Total: a few hundred lines of Apex, deployable in days. MuleSoft adds significant annual licensing cost and an unnecessary failure point. I would flip the decision as soon as: 4+ integrations emerge, compliance requires centralized audit trails, multiple systems need shared transformations, or the roadmap introduces orchestration across systems. For larger multi-system enterprise landscapes the answer is typically the opposite: middleware pays for itself quickly. The key is applying the same framework consistently, not hard-coding ‘always’ or ‘never’. I’d document the decision and the flip conditions so the team revisits when the landscape changes.”
Follow-up: “Six months later, the client acquires a subsidiary with 5 new integration requirements. How do you transition?”
Q3.2: CDC vs Platform Events
Judge: “You chose CDC to notify the warehouse when an Order is created. The warehouse does not need to know which fields changed — just that an order was submitted and needs fulfillment. Have you considered Platform Events?”
What they’re testing: Whether the candidate can distinguish between data change notification (CDC) and custom business event semantics (Platform Events).
Model answer: “Platform Events are better for three reasons. First, custom schema: define exactly the fields the warehouse needs. CDC sends the entire record including irrelevant fields. Second, controlled publish timing: fire only when Order reaches ‘Submitted’ status. CDC fires on every update — noise the warehouse must filter. Third, self-documenting semantics: Order_Fulfillment__e communicates purpose clearly. CDC would be right for replicating field-level changes to the data warehouse for analytics. Trade-off: PE requires explicit publish logic vs CDC’s automatic firing, but the control and clarity are worth the code.”
Follow-up: “What if finance also needs a full audit trail of every field change on the Order?”
Q3.3: Sync blocking UX
Judge: “Your design has the service agent waiting for a 4-second synchronous callout to the billing system before proceeding with the case. Have you considered the impact on the agent’s workflow?”
What they’re testing: Whether the candidate recognizes that a 4-second synchronous block during agent workflow is poor UX.
Model answer: “Four seconds blocks an agent during live customer interaction. At 50 cases/day, that is 3+ minutes of spinner time daily, worse if the billing system spikes to 10-15 seconds. Switch to async pre-fetch: when the case opens, a Queueable fires to fetch payment history and cache in Payment_History__c records. Agent sees cached data immediately with a timestamp. A ‘Refresh’ button triggers on-demand fetch. Cache refreshes every 4 hours for active accounts, daily for inactive. Trade-off: data could be 4 hours stale, but payment history does not change second-by-second. Critical path is unblocked.”
Follow-up: “What if the billing system charges per API call and pre-fetch triples the volume?”
Q3.4: Point-to-point vs middleware threshold
Judge: “Your architecture shows five external systems each connected directly to Salesforce with point-to-point. You want centralized monitoring and governance. Have you considered that point-to-point makes this very difficult?”
What they’re testing: Whether the candidate recognizes the threshold where point-to-point becomes unmanageable and middleware pays for itself.
Model answer: “Five systems with point-to-point produce 10 connection paths, each with independent auth, error handling, retry, and monitoring. Centralized monitoring across 5 P2P integrations means building custom logging and dashboards for each — essentially recreating middleware without middleware. At this count with the governance requirement, middleware is justified. MuleSoft as hub: System API per external system, shared monitoring via Anypoint Monitoring, centralized error handling with Anypoint MQ as DLQ, unified alerting. Significant licensing cost that becomes cost-effective when spread across 5+ integrations, comparable to ongoing custom integration maintenance. Factor in reusability and the ROI is positive within year one.”
Follow-up: “The CFO pushes back on the MuleSoft license cost. What is your alternative?”
Q3.5: ETL vs ELT
Judge: “You are performing complex data cleansing and multi-system joins in Salesforce Apex after loading raw data. Why move this transformation elsewhere?”
What they’re testing: ETL vs ELT trade-off: complex transformations inside Salesforce consume governor limits.
Model answer: “The transformations involve schema mapping across three sources, data type conversions, picklist translation, cross-source dedup, and address standardization. Running all in Apex after loading puts significant pressure on CPU time, SOQL, and heap. If any batch exceeds limits, partially transformed data sits in Salesforce. Move to ETL with MuleSoft: handle schema mapping, conversion, dedup with no governor constraints. Address standardization through a service API. Only clean, validated data enters via Bulk API 2.0. Trade-off: adding middleware complexity, but for three sources with complex transformations, it earns its keep. ELT is acceptable only for simple field renames or formula-level logic.”
Follow-up: “One source system is a legacy mainframe that only exports flat files via SFTP. How does that change the design?”
Type 4: Rationale Missing - “WHY Did You Choose…?”
The judge wants your reasoning, not just the answer.
Q4.1: JWT Bearer justification
Judge: “You recommended JWT Bearer flow for the ERP integration. Why JWT Bearer specifically, and not Client Credentials or Web Server?”
What they’re testing: Whether the candidate can articulate specific reasons for choosing JWT Bearer.
Model answer: “Three reasons. First, server-to-server with no interactive user — Web Server requires a browser login. Second, JWT uses X.509 certificates rather than shared secrets — stronger than standard Client Credentials (shared secret). Note: a JWT Client Credentials variant using certificates exists, but JWT Bearer remains preferred when user-context is needed for sharing rules and audit trails. Third, JWT runs as a specific Salesforce user — data access respects that user’s permissions and sharing rules. Client Credentials runs without user context, defaulting to the Connected App’s execution user. Our integration user has a locked-down permission set with only required objects/fields. Trade-off: JWT requires certificate management (rotation, expiration monitoring) while Client Credentials is simpler. The security benefit justifies the overhead for an enterprise ERP integration.”
Follow-up: “When would you recommend Client Credentials instead?”
Q4.2: Middleware justification
Judge: “Walk me through why you placed a middleware layer between the five external systems and Salesforce. What specific value is it providing?”
What they’re testing: Whether the candidate can justify middleware with concrete architectural benefits specific to the scenario.
Model answer: “Four reasons. First, transformation: three systems use different formats (SOAP/XML, non-standard JSON dates, fixed-width flat files). Without middleware, each lives in Apex consuming governor limits. MuleSoft’s DataWeave handles all three with no limit constraints. Second, fan-out routing: order submission notifies ERP, billing, and DW. Middleware subscribes once and routes to three with per-destination transformation. Third, centralized monitoring: one dashboard for all integration health, not five separate setups. Fourth, reusability: the Salesforce System API is reused by billing and DW. API version changes propagate once. Cost: significant annual licensing cost. At 5 integrations, per-integration cost becomes comparable to custom maintenance. Factor in monitoring, governance, and time saved on the next integration.”
Follow-up: “If the client cannot afford MuleSoft, how do you achieve similar benefits?”
Q4.3: Serial vs parallel Bulk API
Judge: “You chose serial processing mode for the Bulk API 2.0 job. Why not parallel, which would complete faster?”
What they’re testing: Whether the candidate understands when serial is required and can articulate the lock contention trade-off.
Model answer: “Serial mode because this job loads Opportunities sharing parent Accounts. In parallel, concurrent batches compete for row locks on the same Account, causing non-deterministic UNABLE_TO_LOCK_ROW errors. Serial processes one batch at a time, sequentially. Trade-off: 3-5x slower. For 200,000 Opportunities, ~45 minutes serial vs 10-15 minutes parallel. Scheduled at 2 AM Saturday — zero business impact. If records were independent (standalone Contacts with no shared parents), I would use parallel. The decision is data-model-driven. I also sorted the CSV by AccountId so related Opportunities cluster within the same batch.”
Follow-up: “What if the business requires completion within 15 minutes because a downstream integration starts at 2:30 AM?”
Q4.4: PE vs CDC selection criteria
Judge: “For this notification use case, you chose Platform Events over CDC. Both could work. Walk me through your selection criteria.”
What they’re testing: Structured PE vs CDC decision framework beyond surface descriptions.
Model answer: “Four criteria. First, event semantics: the notification is a business event (‘Compliance Review Completed’) spanning multiple records. CDC fires per-object; the subscriber would receive three unrelated change events. PE encapsulates the entire event. Second, payload control: the notification needs computed data (risk score, reviewer name, next review date). CDC sends changed field values but cannot include computed or cross-object data. Third, external publishing: future state includes external systems publishing into Salesforce. CDC only generates from SF DML. PE accepts external publish via REST/Pub/Sub API. Fourth, source filtering: only high-risk reviews (score > 7) should fire. PE: I control when to publish. CDC fires on every change, forcing subscriber-side filtering. CDC would be right for ‘replicate all field changes to the DW.’”
Follow-up: “What if compliance later asks for a full audit trail of every field change?”
Q4.5: Composite API variant selection
Judge: “You mentioned using the Composite API. Salesforce offers Composite, Composite Batch, sObject Tree, and sObject Collections. Which variant and why?”
What they’re testing: Whether the candidate knows the differences between Composite API variants.
Model answer: “Standard Composite (25 subrequests with reference IDs). The onboarding creates dependent records in sequence: Account, then Contact referencing the Account ID, then Opportunity referencing the same Account, then Task assigned to the Contact. Each subrequest uses @{referenceId.id} to chain. Composite Batch does not support inter-subrequest dependencies. sObject Tree can create an Account with child Contacts and child Opportunities in one call (supports multiple child relationship types under one root), with hard limits of 200 records per request, up to 5 different sObject types per request, and up to 5 relationship levels deep — it cannot handle records across unrelated root objects, and it cannot nest deeper than 5 levels. sObject Collections handles bulk CRUD on a single object type (up to 200 records). I set allOrNone=true on Composite so any failure rolls back the entire transaction. Trade-off: all 25 subrequests in a Composite call share governor limits, but 4-5 related records is well within.”
Follow-up: “What if onboarding grows to 30 dependent records, exceeding the 25-subrequest limit?”
Type 5: Cascading - “If You Change X, What Happens to Y?”
The judge is testing cross-domain awareness and cascading impact analysis.
Q5.1: Sync-to-async dashboard cascade
Judge: “You switched order notification from synchronous to asynchronous Platform Events. What cascading impact does that have on the downstream dashboard showing real-time order status?”
What they’re testing: Whether the candidate can trace the full impact chain across dependent systems, reporting, user expectations, and data consistency.
Model answer: “First, dashboard impact: the ERP status field remains ‘Pending’ until the async callback writes the status back (seconds to minutes). Operations managers accustomed to instant confirmation perceive the async pattern as broken. Second, user expectation: add a visual ‘Processing’ badge via LWC with Emp API subscribing to a status update PE for real-time UI refresh. Third, report impact: scheduled reports during the consistency gap may undercount confirmed orders. Adjust report scheduling for max async delay. Fourth, SLA impact: measurement point shifts from ‘order saved’ to ‘ERP callback received.’ SLA definitions need updating.”
Follow-up: “The finance team runs a midnight reconciliation report comparing Salesforce orders to ERP orders. How does async affect that?”
Q5.2: Data model change breaks integration
Judge: “The data team split the Account object into Account and Account_Financial__c for compliance. Your integration sends a single Account payload to the ERP. What breaks?”
What they’re testing: Whether the candidate can trace how a data model change breaks integration contracts, middleware mappings, and downstream expectations.
Model answer: “Multiple levels. First, API contract: ERP expects a flat Account payload. Middleware must now query both objects, join them, and produce the expected structure. Second, CDC subscription: billing field changes no longer fire AccountChangeEvent; a new Account_Financial__c change event needs registration. Third, PE payload: any custom PE including billing fields must be updated. Fourth, Bulk API jobs: SOQL queries for Account with billing fields fail. Fifth, test suite: HttpCalloutMocks returning Account data with billing fields pass but produce incorrect data. Mitigation: versioned middleware APIs — deploy v2 handling the two-object join while keeping v1 alive during transition.”
Follow-up: “How do you handle environments where some sandboxes have the old model and production has not been deployed yet?”
Q5.3: New subscriber delivery impact
Judge: “A sixth external system (fraud detection) becomes a required subscriber for order events. You currently have five subscribers. What is the cascading impact?”
What they’re testing: How adding subscribers affects shared delivery allocations and whether architectural changes are needed.
Model answer: “First, delivery allocation: at 15,000 orders/hour and 6 subscribers, that is 90,000 event deliveries/hour. Verify org allocation can handle it. Second, processing dependency: fraud detection must evaluate before the warehouse ships. This changes from pure fan-out to orchestrated sequence for those two subscribers, possibly requiring a MuleSoft Process API. Third, error isolation: fraud service downtime must not block other subscribers. But if fraud is down and warehouse proceeds, orders ship unverified. Add a circuit breaker for the fraud subscriber that pauses warehouse fulfillment until fraud catches up. Fourth, payload compatibility: fraud may need different data (IP, device fingerprint). Prefer a separate Fraud_Evaluation__e event to maintain clean contracts.”
Follow-up: “The fraud service has a 500ms SLA. How does that interact with async event delivery?”
Q5.4: Middleware outage cascade
Judge: “Your architecture routes all five integrations through MuleSoft. What happens to order processing, billing, DW sync, portal, and inventory if MuleSoft has an outage?”
What they’re testing: Whether the candidate has designed for middleware as a single point of failure.
Model answer: “Impact per pattern: (1) Orders: queue as PEs on the event bus. 72-hour retention buffer. MuleSoft resumes from managed subscription cursor on recovery. Zero loss under 72 hours. (2) Billing: same event buffer. (3) DW nightly sync: skips that night; next run picks up all changes via delta timestamps. (4) Portal: uses CDC directly without MuleSoft — unaffected (hybrid architecture benefit). (5) Inventory: if synchronous and MuleSoft-dependent, data goes stale. Circuit breaker falls back to cached inventory with staleness warning. For critical paths like orders, a secondary failover: after 30 minutes, a scheduled Apex job activates direct REST callouts to ERP, bypassing middleware in degraded mode.”
Follow-up: “How do you prevent the order backlog from overwhelming the ERP when MuleSoft comes back and processes 72 hours of queued events?”
Q5.5: IdP change impact on integrations
Judge: “The security team is migrating the corporate IdP from Okta to Azure AD. How does this affect your integration landscape?”
What they’re testing: Whether the candidate can trace how an IdP change cascades through every OAuth flow, SSO session, and token management point.
Model answer: “Every OAuth flow and SSO session depends on the IdP. Cascade: (1) Connected Apps: issuer URL, token endpoint, authorization endpoint must update to Azure AD. Certificate trust chain may differ. (2) Named Credentials: External Credentials referencing Okta need new endpoint URLs and client registrations. (3) Middleware: MuleSoft Salesforce Connector auth config must point to Azure AD. Anypoint Platform federation may also break. (4) External system tokens: every system obtaining SF tokens through Okta must register in Azure AD. (5) SAML: SSO metadata, certificate, and ACS URL all change. (6) SCIM provisioning: must rebuild in Azure AD. Mitigation: run both IdPs in parallel. Configure SF to accept auth from both. Migrate integrations one by one. Decommission Okta only after all are verified.”
Follow-up: “During parallel-IdP transition, what happens if a token issued by Okta is presented to a system that switched to Azure AD?”
Q5.6: Encryption impact on integrations
Judge: “Shield Platform Encryption is mandated on all PII fields (Name, Email, Phone, SSN, Address). How does this affect your integration payloads?”
What they’re testing: Whether the candidate understands Shield encryption’s impact on API queries, SOQL filters, and integration user permissions.
Model answer: “Cascading effects: (1) SOQL filters: probabilistic encryption breaks WHERE, ORDER BY, GROUP BY. Any integration query filtering by PII fails. Use deterministic encryption for filterable fields. (2) API responses: encrypted fields return plaintext to users with ‘View Encrypted Data’ permission. Each integration user needs this permission for specific fields per least-privilege. (3) Bulk API: query operations subject to the same SOQL filter restrictions. (4) Reporting: encrypted fields cannot be used in report filters unless deterministic. (5) Data migration: loading into encrypted fields works, but validation comparing against existing values must use the API. Audit every SOQL query in Apex and middleware System APIs.”
Follow-up: “The marketing team uses Data 360 for identity resolution. How does Shield interact with Data 360?”
Q5.7: Sandbox refresh breaks Connected Apps
Judge: “Your full-copy sandbox was refreshed. Three of five Connected Apps stopped working. What happened?”
What they’re testing: Whether the candidate understands sandbox refresh impacts on Connected App credentials and integration configurations.
Model answer: “Connected App behavior varies by sandbox type. The primary breakage is usually instance URL changes and token invalidation. Consumer secrets may or may not regenerate depending on sandbox type. External systems storing old instance URLs or tokens fail to authenticate. Fix: (1) Retrieve new consumer secrets (if changed) from each Connected App and update MuleSoft/external configs. (2) Verify sandbox login URL. (3) Re-authenticate each integration. (4) Run test suite. Prevention: document a post-refresh restoration checklist as a runbook. Store sandbox-specific credentials in a secrets manager. Use My Domain URLs rather than instance-specific URLs. Important platform note for 2026 and beyond: as of Spring ‘26, new Connected App creation is disabled in all orgs. Existing Connected Apps continue to function, but any new integration work should use External Client Apps (ECAs). The post-refresh process is the same in spirit, but the object you’re updating is an ECA, not a Connected App.”
Follow-up: “How do you handle the gap between sandbox refresh and credential restoration when QA is trying to run tests?”
Q5.8: MC Connect to Data 360 migration
Judge: “The marketing team wants to migrate from MC Connect to Data 360 for contact synchronization. Journey Builder entry sources are tied to Synchronized DEs. Walk me through the cascading impacts.”
What they’re testing: Understanding of MC Connect vs Data 360 architectural differences and full migration impact.
Model answer: “Cascade: (1) Data model: MC Connect creates flat Synchronized DEs. Data 360 uses unified profiles with identity resolution. Journeys referencing DE fields must be rebuilt for Data 360 profile attributes. (2) Journey entry: current Salesforce Data Events from MC Connect must change to Data 360 segment-based activation. Every entry config is redesigned. (3) Synchronized DE deprecation: Automation Studio SQL queries joining Synchronized DEs break when they stop refreshing. (4) Contact billing: MC Connect counts every synced record. Data 360 activation volumes may differ depending on segment definitions. (5) Latency: MC Connect is near-real-time (minutes). Data 360 batch segments recalculate on schedule; streaming segments are near-real-time. Migration path: run both in parallel, migrate journeys one at a time starting with low-risk campaigns.”
Follow-up: “During parallel-run, both systems push contact data into MC. How do you prevent duplicates?”
Always verify against official Salesforce documentation
This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.
Related Topics
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.