Domain Grilling: D1 System Architecture

System Architecture is the broadest CTA domain: org strategy, licensing, mobile, reporting, document management, and platform capabilities. Judges probe the reasoning behind major structural decisions. Org strategy alone can make or break a board attempt.

Type 1: Invalid - “Your Solution Won’t Work”

The judge believes your approach is technically incorrect or impossible.

Q1.1: Briefcase Offline with 80,000 Records

Judge: “Your architecture shows field technicians using Briefcase to sync 80,000 work order records with attached PDFs for offline access. That exceeds platform limits. How do you fix this?”

What they’re testing: Knowledge of Briefcase Builder per-user record limits and its unsuitability for heavy file-based offline workflows.

Model answer: “You’re right. Briefcase Builder has a hard ceiling of 50,000 records per user across all rules on the Salesforce Mobile App Plus license, and Salesforce recommends staying near 500 records per object per user for sync performance. Briefcase also syncs record data, not file attachments at scale. I’d scope each technician’s Briefcase to a rolling 7-day window of assigned Service Appointments plus related Work Order and Asset records, bringing each user down to a few hundred records. For PDF manuals and images, move to Field Service Mobile’s native offline Knowledge capability for article/document caching. If the scenario truly requires heavy offline file access, the path is Mobile SDK with SmartStore (encrypted local SQLite limited only by device capacity) with MobileSync for bidirectional sync. Trade-off: Briefcase plus FS Mobile for standard workflows, Mobile SDK only when offline file volume demands it.”

Follow-up: “The recommended ~500 records per object target is well below the 50,000 per-user hard cap. Walk through how you’d enforce that soft target in your rule design when a technician’s 7-day work order window spikes past 500 records.”

Q1.2: Platform Licenses for Case-Handling Team

Judge: “You’ve assigned Platform Plus licenses to your claims processing team, but your design shows them creating and managing Cases with entitlements and milestones. Walk me through the correction.”

What they’re testing: Understanding the Platform license object scope — particularly that Platform Starter excludes Cases and that even Platform Plus (which does include Cases) is blocked by missing Service Cloud features like Entitlements, Milestones, and Omni-Channel.

Model answer: “Hard blocker, but for the right reason. Platform Starter includes Accounts, Contacts, Reports, Dashboards, Tasks, Events, Notes, Documents, Custom Objects, plus core system objects — but excludes the sales/service/support objects: Leads, Opportunities, Campaigns, Forecasts, Cases, Solutions. Platform Plus expands that envelope to include Cases and read-only access to a few more CRM objects, so Platform Plus users can technically see and create Cases. The blocker here is the entitlements and milestones requirement: Service Cloud features (Entitlement Processes, Milestones, Service Console, Omni-Channel, Knowledge for service) are not available on Platform licenses regardless of object access. If the team needs SLA tracking with entitlement timers, they need Service Cloud licenses. Cost optimization: audit how many staff truly need the Service Cloud feature stack vs those who could work through a custom Claims object or Platform Plus Case access without SLA mechanics. Split into direct case handlers (Service Cloud) and supervisors reviewing aggregate metrics (Platform Plus dashboards), reducing Service Cloud seat count by 30-40%. Rejected alternative: rebuilding Cases as a custom object. You lose Entitlements, Milestones, Omni-Channel, Service Console, and Knowledge integration. Development cost dwarfs license savings.”

Follow-up: “If 200 back-office users exist and only 120 truly need Case access, what’s the annual cost difference between Service Cloud for all 200 versus a mixed-license approach?”

Q1.3: Standard Reports for Cross-System Analytics

Judge: “Your reporting architecture recommends standard reports for executive cross-system analytics combining ERP, Marketing Cloud, and Salesforce pipeline data. Standard reports can’t do that. What’s your alternative?”

What they’re testing: Understanding that standard reports are Salesforce-only and cannot query external data sources.

Model answer: “Correct. Standard reports query only data native to the Salesforce org. Two paths: (1) Tableau if executives consume dashboards outside Salesforce, data lives in a Snowflake/BigQuery warehouse, and Tableau connects natively. Creator licenses for builders, Explorer/Viewer for consumers. Embed in Lightning if executives also work in Salesforce. (2) CRM Analytics with Recipes to ingest external data alongside Salesforce data if executives primarily live inside Salesforce and external data volume is manageable. Deciding factor: where executives spend their day and whether a data warehouse already exists. Keep standard reports for operational Salesforce-only reporting for sales managers and service leads.”

Follow-up: “If you choose CRM Analytics, what are the refresh frequency limitations for dataflows pulling from external sources, and how does that affect real-time expectations?”

Q1.4: Single Org with Dual Data Residency

Judge: “Your solution proposes a single org for a global financial company with hard EU data residency and US data residency requirements simultaneously. How do you reconcile this?”

What they’re testing: Understanding that a single org cannot guarantee simultaneous multi-region data residency, and Hyperforce has processing limitations.

Model answer: “A single org sits on one instance in one region. Even with Hyperforce, it cannot simultaneously guarantee EU-only and US-only processing for different record sets within the same org. This is a multi-org forcing function. Two orgs: one on Hyperforce EU for European operations, one in US for American operations. Each gets its own data residency guarantee. For shared customers, MuleSoft with API-led connectivity provides a unified view with sanitized/tokenized references, not raw PII across jurisdictions. Trade-off: duplicate admin teams, paired sandboxes, shared IdP federation to both orgs. Regulatory requirement makes this unavoidable. Additional audit items: sandbox refreshes can cause cross-border data flows, URL structures and dynamic IP addressing change with Hyperforce migration, and email routing may traverse non-local infrastructure.”

Follow-up: “What specific Hyperforce limitations around email routing, Einstein AI processing, and AppExchange data handling could create cross-border data flow even with the two-org setup?”

Q1.5: Over-Engineered Reporting

Judge: “You’ve recommended CRM Analytics with Einstein Discovery for a department needing three pie charts: case volume by status, average resolution time, and agent workload. That’s over-engineering. Why did you reach for CRM Analytics here?”

What they’re testing: Understanding the reporting escalation principle: standard reports are the default, CRM Analytics only when a specific gap demands it.

Model answer: “You’re right. Those three requirements are single-object aggregations on Cases. Standard reports handle all natively: Summary report grouped by Status, Summary with average formula on Resolution Time, Matrix report with Case Owner rows and Status columns. All three fit on a standard dashboard with no join complexity, external data, or predictive modeling. CRM Analytics adds per-user license cost, SAQL learning curve, and dataflow governance unjustified by basic aggregations. I’d reserve CRM Analytics for escalation triggers: joining 4+ objects, trending beyond 3 months, predictive scoring, or combining with external data.”

Follow-up: “At what point would you add CRM Analytics for this service team? Name two or three specific requirements that justify the escalation.”

Type 2: Missed - “You Haven’t Addressed…”

The judge is pointing out a gap in your design.

Q2.1: Disaster Recovery and Business Continuity

Judge: “I don’t see disaster recovery or business continuity in your architecture. This is mission-critical for a financial services firm. What happens if the Salesforce instance goes down?”

What they’re testing: DR/BCP responsibilities even on a multi-tenant platform, including backup strategy, degraded-mode operations, and RTO/RPO planning.

Model answer: “Significant gap. Four dimensions: (1) Data backup: implement OwnBackup or similar ISV for daily/near-real-time backup of critical objects (Salesforce weekly export RPO is too coarse). (2) Degraded-mode operations: a read-only cache layer in middleware (MuleSoft + Redis/Postgres) holding last-known state of active cases and work orders so the contact center operates with limited functionality. (3) RTO/RPO targets: RPO of 1 hour, RTO of 4 hours for financial services. (4) Communication plan: automated monitoring on trust.salesforce.com triggering BCP activation playbook. Trade-off: DR/BCP adds infrastructure cost and requires failover testing and data reconciliation after primary recovery.”

Follow-up: “How would you test the DR/BCP plan? Describe the tabletop exercise and quarterly failover drill.”

Q2.2: Document Management Compliance Lifecycle

Judge: “Your solution includes document generation but nothing about legal hold, retention policies, or compliance audit trails. In a regulated industry, that’s a gap. What’s your document management strategy?”

What they’re testing: Document lifecycle architecture beyond generation: retention, legal hold, compliance requirements.

Model answer: “Salesforce Files lacks native legal hold, automated retention enforcement, and granular document-level audit trails. For regulated industries, integrate with external DMS: SharePoint provides legal hold via Microsoft 365 Compliance Center, automated retention labels, and full audit trail of every access/modification. Architecture: documents generated via AppExchange tool (Conga/Documate), stored in SharePoint via Files Connect, retention labels auto-applied based on document type and record stage. Legal hold requests lock affected documents, preventing deletion even by admins. Trade-off: dual permission model (Salesforce sharing + SharePoint permissions) creates governance burden. Mitigate by synchronizing access groups through the IdP.”

Follow-up: “If using Files Connect with SharePoint, what are the latency implications when users access documents from Salesforce, and how does that affect the mobile experience?”

Q2.3: Field Service Scheduling at Scale

Judge: “You have 3,000 field technicians across 40 territories but your architecture doesn’t address scheduling optimization. How are you handling job assignment at that scale?”

What they’re testing: Field Service scheduling engine architecture: ESO, scheduling policies, work rules, service objectives, and territory-scoped optimization.

Model answer: “Critical gap. Three layers: (1) Scheduling policies: two policies — emergency repairs with ASAP highest-weighted, and planned maintenance with Minimize Travel primary. Emergency uses drip-feed scheduling; planned uses overnight bulk optimization per territory. (2) Work rules as constraint filters: Match Skills, Match Territory, Maximum Travel from Home, and Service Resource Availability. (3) Territory design: 40 territories averaging 75 technicians each exceeds the 50-resource best practice. Subdivide the largest into dispatch zones of 40-50 technicians, giving roughly 60-70 zones. Optimize per zone, not globally. Trade-off: more territories = more governance overhead, but optimization quality and dispatcher workload justify the structure.”

Follow-up: “How do you handle technicians who work across territory boundaries — a specialist covering two adjacent zones? Walk me through the membership model.”

Q2.4: Sandbox Strategy for Parallel Teams

Judge: “You have four parallel development teams in one org but no sandbox strategy. How do they develop and test without stepping on each other?”

What they’re testing: Sandbox strategy tied to edition capabilities: allocation, parallel development isolation, integration testing.

Model answer: “Enterprise default allocation: 25 Developer and 1 Developer Pro. Partial Copy and Full Copy sandboxes are not included with Enterprise — they are purchasable add-ons. Assume we’ve purchased 1 Partial Copy and 1 Full sandbox for this scenario (call that out to the judge so there’s no ambiguity about what’s default vs bought). Allocate 6 Developer sandboxes per team, leaving 1 shared. Partial Copy = UAT, Full = staging. Bottleneck: Partial has a 5-day refresh interval, Full has 29 days. On Unlimited: 100 Developer and 5 Developer Pro included, with 1 Full Copy included. 20+ Developer sandboxes per team, dedicated Developer Pro for integration testing per team. Release process: Developer sandboxes > Developer Pro (integration testing) > Partial Copy (UAT with realistic data) > Full (staging) > Production. The edition cost delta against productivity impact of constrained sandbox availability plus the need to buy Full/Partial separately on Enterprise is a strong argument for Unlimited above a certain scale.”

Follow-up: “If one team’s metadata deployment to shared staging breaks another team’s functionality, what’s your rollback strategy?”

Q2.5: Agentforce Security Boundaries

Judge: “Your Agentforce implementation shows autonomous AI agents handling scheduling and case triage, but you haven’t addressed security boundaries or guardrails. What prevents an agent from accessing records it shouldn’t?”

What they’re testing: Agentforce security architecture: trust layer, guardrails, topic boundaries, human-in-the-loop controls.

Model answer: “Three security boundaries: (1) Topic and action boundaries: scope each agent to specific Topics (what it can discuss) and Actions (what it can do). Scheduling agent: appointment booking/rescheduling only. Triage agent: case categorization and routing only. Neither gets delete, permission modification, or financial data actions. (2) Data access controls: agents operate in the running user’s permission context. Customer-facing agents inherit portal user’s profile/sharing. Internal agents use a dedicated minimum-access service user with targeted permission sets. (3) Guardrails: high-impact actions (escalation, off-hours booking) require human approval. Dispatchers retain override control. Trade-off: tighter guardrails reduce autonomous efficiency, so progressively loosen as confidence builds.”

Follow-up: “How does Flex Credit consumption work for Agentforce? Each action costs $0.10 (20 Flex Credits), with Voice actions at 30 Flex Credits. Walk through how a typical service interaction consumes credits across data lookups, reasoning steps, and actions.”

Type 3: Suboptimal - “Have You Considered…?”

The judge is suggesting a potentially better approach.

Q3.1: Hyperforce vs Multi-Org for Data Residency

Judge: “You’ve proposed multi-org for this global manufacturer with plants in Germany, US, and Japan. Have you considered whether Hyperforce could solve the data residency requirement within a single org?”

What they’re testing: Whether the candidate exhausted single-org with Hyperforce before jumping to multi-org.

Model answer: “Valid challenge. Hyperforce deploys the org in a specific cloud region, providing data-at-rest residency. If German regulators only require EU data-at-rest residency (not processing isolation), single-org on Hyperforce EU is viable. US and Japanese users connect with some latency, mitigated by CDN caching and Lightning UX optimization. Total cost comparison favors single-org significantly: multi-org means three license sets, three admin teams, three sandbox strategies, MuleSoft integration layer, and 2-3x operational cost. However, if any region has hard processing-in-country requirements, or plants operate independently with zero shared customers, multi-org becomes justified. Ask legal for the specific regulatory language before committing.”

Follow-up: “What Hyperforce limitations would you audit for this manufacturer regarding email routing, Einstein processing, and AppExchange vendor data handling?”

Q3.2: Platform License Right-Sizing

Judge: “You’ve given full Sales Cloud licenses to 150 warehouse staff who only use a custom inventory app. Have you considered Platform licenses?”

What they’re testing: License right-sizing: Platform licenses for users needing only custom app access.

Model answer: “Over-provisioning. If warehouse staff only interact with custom objects for inventory and never touch Opportunities, Cases, or Campaigns, Platform Plus covers them at a fraction of the cost. Audit object dependencies first: if any page layout, flow, or trigger references CRM objects even indirectly, Platform won’t work. At 150 users, the annual cost difference could be several hundred thousand dollars. Trade-off: governance — two license types require managing which users get which, preventing Platform users from being added to permission sets that reference CRM objects, and handling the occasional warehouse manager who gets promoted to a sales role.”

Follow-up: “If a warehouse manager gets promoted and needs Opportunity access, what’s the license upgrade process?”

Q3.3: Reporting Snapshots vs CRM Analytics

Judge: “You’ve recommended CRM Analytics for a small 30-user sales team needing pipeline trending over 6 months. Standard trending only covers 3 months, but have you considered Reporting Snapshots?”

What they’re testing: Knowledge of Reporting Snapshots as a middle ground between standard reporting and CRM Analytics.

Model answer: “CRM Analytics is heavy for what’s essentially a trending gap. Reporting Snapshots (formerly Analytic Snapshots) bridge this: schedule a weekly snapshot capturing pipeline data into a custom object. Over 6 months, that produces 26 weekly snapshots. Standard reports on the snapshot object show pipeline trending over any period. CRM Analytics requires per-user PSLs, dataflow admin, and SAQL knowledge. Reporting Snapshots use standard functionality at zero additional licensing. Trade-off: CRM Analytics gives interactive drill-down, SAQL calculations, and Einstein Discovery predictions. Reporting Snapshots give static historical records. For 30 users needing month-over-month trending, snapshots are sufficient. I’d add CRM Analytics when predictive deal scoring or cross-object trending is needed.”

Follow-up: “If the sales VP later wants predictive pipeline analytics, does that change your recommendation? At what point does the CRM Analytics investment become justified?”

Q3.4: PWA vs Mobile SDK

Judge: “You’ve proposed Mobile SDK for a customer-facing service portal. That’s a significant investment. Have you evaluated whether a PWA on Experience Cloud would meet the requirements?”

What they’re testing: Whether the candidate considered the full mobile spectrum before jumping to the most expensive option.

Model answer: “Should have walked the mobile spectrum first. The portal needs: branded app-store presence, case submission, knowledge browsing, appointment scheduling, and basic push notifications. None require native device integration or complex offline sync. A PWA covers all functionality; Mobile Publisher wraps it into a branded app-store listing with custom icon, splash screen, and biometric login — satisfying branding without custom code. Mobile SDK would only be justified for complex offline bidirectional sync, deep device hardware integration, or performance-critical real-time interactions. The cost difference is substantial: Mobile SDK means hiring iOS/Android developers, dual codebase maintenance, app store submission cycles, and 2-4x initial development cost for 3-year maintenance.”

Follow-up: “What iOS limitations should you warn about with the PWA approach? How does Apple’s stance on web apps affect portal capability on iPhones?”

Q3.5: Unlocked Packages vs Multi-Org

Judge: “You’ve recommended separate orgs for two BUs that share no customers but use the same ERP integration, same IdP, and same governance team. Have you considered unlocked packages?”

What they’re testing: Unlocked packages as a single-org modularity mechanism providing BU isolation without multi-org overhead.

Model answer: “Strong challenge. With shared infrastructure (same ERP, IdP, governance team) and zero shared customers, the operational overhead of two orgs is hard to justify. Unlocked packages give each BU modular metadata boundaries: separate objects, flows, Apex classes, deployed independently through their own package versions. Single org provides: shared identity management, one ERP connection (not two), unified governance, pooled limits and storage. Multi-org costs double: two license sets, AppExchange subscriptions, admin teams, and an inter-org integration layer if they ever share data. Start with single-org plus packages. Multi-org is justified only if packaging can’t absorb release cadence conflicts or regulatory changes force data isolation.”

Follow-up: “If one BU’s batch processes consume 60% of the org’s daily async Apex execution limit, how do you isolate resource consumption within a single org?”

Type 4: Rationale - “WHY Did You Choose…?”

The judge wants to hear the reasoning behind a correct decision.

Q4.1: Single-Org Justification

Judge: “Walk me through your reasoning for recommending a single org. What specific scenario factors drove the decision, and what would change your mind?”

What they’re testing: Structured single-org justification tied to scenario specifics, not generic preference.

Model answer: “Three factors: (1) Shared customers with 40% overlap — splitting creates duplicate records with constant sync or cross-org integration for unified view. Single org eliminates this natively. (2) Unified reporting — CEO’s dashboard across both BUs requires queryable data from one place. Two orgs means CRM Analytics with cross-org connectors or Tableau dual data sources, less reliable than native reporting. (3) Single governance team with same release cadence and compliance requirements — no governance conflict demanding separation. Trade-offs I accept: shared governor limits (implement monitoring dashboards for API/storage/async consumption), shared metadata (use permission sets and custom permissions to isolate features). What changes my mind: hard regulatory requirement for data isolation (FedRAMP for one BU), or irreconcilable release cadences that packaging cannot absorb.”

Follow-up: “The customer just told you one BU is pursuing FedRAMP certification. Does that change your single-org recommendation?”

Q4.2: Tableau vs CRM Analytics

Judge: “You chose Tableau over CRM Analytics for this customer’s analytics platform. What was the deciding factor?”

What they’re testing: Ability to name the specific deciding factor rather than listing features.

Model answer: “Deciding factor: consumer persona. Primary consumers are finance and operations executives who don’t use Salesforce — they live in Excel, email, and the intranet. They will never log into Salesforce for a CRM Analytics dashboard. Tableau serves non-Salesforce users natively through Tableau Server/Cloud — bookmarked URLs, scheduled email snapshots, interactive exploration without a Salesforce license. Secondary factor: multi-source data. The requirement combines Salesforce pipeline, SAP financial actuals, and supply chain data. Tableau connects to all three natively. CRM Analytics can ingest external data but isn’t designed as enterprise-wide BI across five sources. Trade-off: Tableau requires its own infrastructure and admin team. For Salesforce-native users, I’d still use standard reports.”

Follow-up: “If finance later wants Salesforce pipeline data refreshed in Tableau every 15 minutes, what architecture pattern provides near-real-time freshness?”

Q4.3: Edition Economics

Judge: “You recommended Enterprise Edition over Unlimited for a 200-user deployment. Walk me through the cost-benefit analysis.”

What they’re testing: Ability to model edition economics with specific numbers rather than vague preference.

Model answer: “Per-feature cost modeling, not blanket upgrade. Storage: 15M records at ~2 KB avg = 30 GB. Enterprise’s 14 GB (10 GB + 200 x 20 MB) falls short, requiring storage add-on. Unlimited’s 34 GB (10 GB + 200 x 120 MB) covers it. But model the add-on cost vs per-user delta across 200 users. API: integration makes ~150K calls/day. Enterprise with 200 users provides an org-wide allocation covering that need. Unlimited would give far more, but more than needed. Premier Support: compare the 30% add-on on Enterprise vs included with Unlimited. After modeling storage add-on + Premier add-on + API headroom + per-user price delta, Enterprise plus add-ons came in ~25% cheaper for this user count. At 500 users the math would flip. Trade-off: Enterprise has 25 dev sandboxes vs 100 — mitigate with strict coordination and unlocked packages.”

Follow-up: “At what user count does the break-even flip in favor of Unlimited given these storage and API requirements?”

Q4.4: On-Platform Justification

Judge: “Your design keeps the order management workflow on-platform using Flows and Apex. Justify not moving it to an external microservice given the complexity.”

What they’re testing: Articulating the platform-first decision with specific trade-offs and the threshold for going off-platform.

Model answer: “Three platform feasibility criteria met: (1) Governor limits: single orders touch 5 objects, ~15 SOQL, ~8 DML — well within sync limits. Nightly batch of 10K orders uses Batch Apex at scope 200, within async limits. (2) Users already in Salesforce: the team works in the Sales Console. External microservice means context-switching or re-embedding, adding integration complexity for the same UX. (3) Maintenance cost: on-platform = Salesforce handles infrastructure/security/upgrades. External microservice requires its own hosting, monitoring, CI/CD, and separate team skills. 5x maintenance heuristic: microservice 3-year TCO = 3-5x initial build. What pushes off-platform: sub-second response with complex pricing hitting CPU limits, 10+ external system orchestrations exceeding callout limits, or nightly batch exceeding the 24-hour execution window. None exist here.”

Follow-up: “If nightly orders grow from 10,000 to 500,000, at what point does Batch Apex hit a ceiling and what’s the escalation path?”

Type 5: Cascading - “If You Change X, What Happens to Y?”

The judge is testing whether you can trace impacts across domains.

Q5.1: Org Split Cascade

Judge: “The board just told you to split this into two orgs due to a regulatory requirement you missed. Walk me through every downstream impact.”

What they’re testing: Holistic cross-domain thinking: how org strategy change cascades into identity, data, integration, security, dev lifecycle, and communication.

Model answer: “Domain-by-domain cascade. D2 Identity: single SSO becomes two Connected Apps. Users in both orgs need separate user records, IdP handles routing. Sharing model redesigned independently per org since OWD/roles don’t cross boundaries. D3 Data: MDM strategy needed — which org masters Accounts/Contacts/Products? External ID mapping via shared GUID in middleware. Historical data migration: which records go where? D5 Integration: surface area roughly doubles. Every external system needs connections to both orgs. MuleSoft becomes critical. API budget split per org. Platform Events between orgs need event relay through middleware. D6 Dev lifecycle: sandbox strategy doubles. Paired sandboxes for cross-org integration testing with coordinated refreshes. CI/CD splits into two parallel streams with cross-org integration test gate. D4 Solution: AppExchange packages evaluated per org independently, potentially duplicate licenses. D7 Communication: system architecture diagram redrawn showing both orgs with integration layer. Cost model rebuilt with two license sets plus MuleSoft investment.”

Follow-up: “What’s your realistic timeline for the org split, and what coexistence strategy keeps users productive during the transition?”

Q5.2: Edition Downgrade Cascade

Judge: “The customer is downgrading from Unlimited to Enterprise Edition to cut costs. What breaks in your architecture?”

What they’re testing: Edition-specific capabilities and cascading impact of downgrade on API limits, sandbox allocation, storage, and features.

Model answer: “API allocation: org-wide total drops from base + 5,000 per user license to base + 1,000 per user license. For 300 users: the org-wide budget shrinks dramatically. If integration consumes more than the new allocation, redesign to bulk patterns, CDC/PE to replace polling, Composite API to reduce count, or purchase API packs. Sandboxes: 100 Dev to 25, 5 Dev Pro to 1. Four teams at 6-8 sandboxes each = at capacity with zero room. Restructure around scratch orgs and unlocked packages. Storage: 120 MB to 20 MB/user. 300 users: 46 GB to 16 GB. If current usage exceeds 16 GB, purchase storage or implement archival. Premier Support: no longer included. Custom objects: 2,000 to 200 — hard blocker if org uses more than 200. Each is addressable individually, but compound cost of API packs + storage add-ons + Premier + Einstein add-ons may erode or eliminate the savings.”

Follow-up: “After modeling all add-on costs to maintain current functionality on Enterprise, what’s the actual savings vs staying on Unlimited?”

Q5.3: Mobile SDK Cascade

Judge: “The product owner changed mobile strategy from Salesforce Mobile App with Briefcase to Mobile SDK with SmartStore. Walk me through the cascade.”

What they’re testing: How a mobile strategy change ripples into development, security, integration, cost, and release management.

Model answer: “Development: Salesforce admin configuring Briefcase replaced by iOS/Android or React Native team needing SmartStore and MobileSync expertise. Integration D5: Mobile SDK requires Connected App with OAuth (Authorization Code + PKCE). Every data access becomes explicit REST API calls consuming API budget (200 users x 50 calls/session = 10K additional daily calls). Security D2: SmartStore uses AES-256 on device, but data is locally held outside full platform control. MDM becomes critical: remote wipe, containerization, jailbreak detection, certificate pinning. Connected App OAuth policies need careful scoping. Testing D6: release cycle splits — Salesforce metadata deploys via existing pipeline, mobile app has its own build/test/app-store submission adding 1-3 days per release. Backward compatibility between app and API versions required. Cost D1: Mobile SDK development = 4-6 months initial, 2-4x ongoing maintenance for 3 years. Three-year cost difference vs Briefcase could be $500K+.”

Follow-up: “If you go React Native to reduce dual-platform maintenance, what trade-offs does that introduce vs native Swift and Kotlin?”

Q5.4: Tableau Migration Cascade

Judge: “The analytics team shifted the reporting strategy from standard Salesforce reports to Tableau for all reporting. What downstream changes does that force?”

What they’re testing: How a reporting strategy change cascades into data architecture, integration, licensing, infrastructure, and user training.

Model answer: “Data pipeline D3/D5: standard reports query at execution time with zero ETL. Tableau requires extract-based refreshes or live connections consuming API calls. API budget impact: 50 users x 5 views/day x 10 dashboards = 25K API calls daily just for reporting. Licensing D1: entirely separate license stack — Creator, Explorer, Viewer plus Tableau Server/Cloud infrastructure. Infrastructure D6: new CI/CD tier for Tableau Server provisioning, backup, monitoring. UX D7: sales managers who ran quick reports from Sales Console now open a separate tool, adding friction. Push back on ‘all’ reporting to Tableau: the escalation principle says standard reports handle operational Salesforce-only analytics. Tableau handles cross-system enterprise BI. Moving everything over-engineers the operational layer and adds unnecessary friction and cost.”

Follow-up: “How would you convince the analytics team to keep operational reports on the standard platform while using Tableau for enterprise analytics?”

Judge: “You recommended Sales Cloud, Platform Plus, and Customer Community licenses. Now the customer wants sharing rules between internal and external users, but Customer Community doesn’t support role hierarchy. What cascades?”

What they’re testing: How license type constraints cascade into sharing model, security, and potential upgrades.

Model answer: “Customer Community bypasses standard role hierarchy. All users share a single implicit role, so criteria-based and ownership-based sharing rules based on roles don’t work. Cascade: (1) Sharing model redesign D2: switch to sharing sets using Account/Contact lookup. Fails for cross-account visibility or hierarchical visibility patterns. (2) Licensing escalation: upgrade affected users to Customer Community Plus (3-level portal role hierarchy, sharing rules, API access). At 10,000 users, cost is significant — audit whether all need hierarchical sharing or just the 500 account administrators. (3) Architecture compromise if budget can’t absorb Plus: implement Apex-managed sharing to programmatically create share records simulating role-based visibility. Trade-off: development complexity and share table overhead at scale requiring recalculation monitoring.”

Follow-up: “If you implement Apex-managed sharing for 10,000 portal users, what’s the performance impact on share table recalculation?”

Q5.6: M&A Coexistence Timeline

Judge: “An acquisition was announced. The acquired company has its own org with 5,000 users and a heavily customized data model. Walk through your coexistence and consolidation timeline.”

What they’re testing: M&A coexistence architecture: phased approach, interim integration, identity federation, data mapping.

Model answer: “Four phases over 12-18 months. Phase 1 (weeks 1-8): Assessment and Coexistence. Both orgs keep running independently. Key questions: customer overlap percentage, data model alignment feasibility within 6 months, edition/regulatory blockers. Federate identity via shared IdP. Build lightweight read-only integration (Salesforce Connect cross-org adapter). Phase 2 (weeks 4-24): Interim Integration. MuleSoft system APIs abstracting each org’s data model, process APIs for cross-org workflows (e.g., order-to-cash). Establish external ID mapping (shared GUID). Phase 3 (weeks 16-52): Data Migration and Metadata Alignment. Data mapping, 40% account deduplication, relationship-preserving migration, security model redesign. Phase 4 (weeks 48-72): Cutover. Production migration over coordinated weekend with rollback plan. 90-day read-only decommission window for reference. At each phase: identity goes from separate to federated to consolidated, data from isolated to cross-referenced to merged.”

Follow-up: “If Phase 1 reveals fundamentally incompatible data models, how does that change your timeline and approach?”

Q5.7: Governor Limit Breach Cascade

Judge: “A batch process reconciling 50,000 orders nightly is now hitting CPU limits after data volume doubled to 100,000. The team wants to move processing to AWS Lambda. Walk through all implications.”

What they’re testing: Whether async patterns should be exhausted before moving off-platform, and the full cascade of that decision.

Model answer: “First exhaust on-platform: (1) Reduce scope from 200 to 50 so each execute processes fewer records within CPU budget. Optimize SOQL indexes. Replace CPU-heavy logic with pre-computed values or formula fields. (2) If insufficient, break into Queueable chains (no enforced chain depth limit in production; set a voluntary ceiling via AsyncOptions.MaximumQueueableStackDepth to prevent runaway chains). If both fail, Lambda cascade is significant: Integration D5: Bulk API 2.0 for extract, external processing, Bulk API for upsert. VPC/NAT gateway configuration, IP whitelisting. Security D2: Connected App with OAuth client credentials, secrets in AWS Secrets Manager, minimum-access integration user. Infrastructure D6: new CI/CD pipeline, CloudWatch monitoring, dead letter queues, error reconciliation. TCO D1: Lambda compute is cheap, but surrounding infrastructure, monitoring, security, and deployment maintenance add up. Model 3-year TCO against on-platform optimization cost.”

Follow-up: “If you optimize batch scope from 200 to 50, increasing iterations from 500 to 2,000, what’s the impact on total execution time and the 24-hour async limit?”

Judge: “A new GDPR ruling requires all EU data stored and processed exclusively in the EU. Your current architecture has a single org on a US instance. Walk through the full cascade.”

What they’re testing: End-to-end impact of data residency requirement change: Hyperforce migration vs multi-org, integration rerouting, compliance documentation.

Model answer: “Two paths. Path 1: Single-org migration to Hyperforce EU. If business tolerates all data in EU, migrate existing org. But audit every data flow: email relay (may route non-EU), Einstein AI (may process in specific regions), AppExchange packages (each ISV’s processing location), MuleSoft runtimes (redeploy to EU CloudHub workers). Cascade: Hyperforce migration project, full data flow audit, potential AppExchange replacements, middleware redeployment, updated Data Processing Agreements and Records of Processing Activities. Path 2: Multi-org with EU org. If US regulators also mandate US-only processing, create second org. Full cascade: identity federation, MDM for shared customers, MuleSoft integration layer, doubled sandboxes, coordinated releases. Data migration requires classification exercise identifying all EU customer records, with legal review of cross-border transfer during migration itself.”

Follow-up: “During the Hyperforce migration maintenance window, how do you plan for downtime in a 24/7 global operation?”

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.

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.