Domain Grilling: D4 Solution Architecture
Solution Architecture covers declarative versus programmatic selection, AppExchange evaluation, build versus buy decisions, CPQ/Revenue Cloud, Commerce architecture, and modern platform features like Agentforce. Judges test whether candidates can justify each technology choice with specific reasoning and show awareness of the full solution design spectrum.
Type 1: Invalid - “Your Solution Won’t Work”
The judge believes your approach is technically incorrect or impossible.
Q1.1: Flow with Governor Limit Violations
Judge: “Your Record-Triggered Flow on Opportunity loops through 200 Order Line Items and performs an Update Records element inside the loop for each item. This will hit the 150 DML limit and fail. How do you revise your solution?”
What they’re testing: Flow governor limit awareness, bulkification anti-pattern recognition, and the ability to pivot to a correct solution under pressure.
Model answer: “You are correct. Performing DML inside a loop is an anti-pattern that violates the 150 DML statement limit. I will revise to use a collection variable: inside the loop, assign updated values to a record variable and add it to a record collection. After the loop completes, perform a single DML update on the entire collection outside the loop. This reduces 200 DML statements to 1. If data volume scales beyond this or requires complex processing, I would pivot to Batch Apex which processes records in configurable chunks with dedicated governor limits per batch.”
Follow-up: At what volume threshold would you switch from the collection approach to Batch Apex?
Q1.2: Screen Flow as Background Process
Judge: “You proposed using a Screen Flow to handle the nightly data sync processing from the ERP system. A Screen Flow requires a user interface and active user interaction to progress. This solution will not work. How will you fix this?”
What they’re testing: Understanding of Flow types and their execution contexts. Screen Flows are for interactive UI, not headless background processing.
Model answer: “You are right. A Screen Flow is designed for interactive user experiences and cannot run headlessly. I will change my recommendation to Batch Apex scheduled via the Schedulable interface. Given that this is a nightly ERP data sync, Batch Apex handles high data volumes with configurable chunk sizes, implements retry logic per batch, and provides robust error handling. For lower volumes, a Schedule-Triggered Flow could work, but the ERP sync likely involves complex data transformations and high volume that justify programmatic processing.”
Follow-up: If the nightly sync involved only 5,000 records with simple field mapping, would you still recommend Batch Apex?
Q1.3: SBQQ for Greenfield
Judge: “You recommended implementing the legacy Salesforce CPQ managed package (SBQQ) for this greenfield customer’s quoting architecture. However, Salesforce ended new sales of SBQQ in March 2025. This customer cannot purchase licenses for it. Your solution is invalid. What is your alternative?”
What they’re testing: Platform evolution awareness, specifically the March 2025 end-of-sale for legacy CPQ (SBQQ) and knowledge of the modern replacement.
Model answer: “I acknowledge that legacy CPQ (SBQQ) reached end-of-sale in March 2025 and is no longer available for new customers. I will revise to recommend Agentforce Revenue Management (formerly Revenue Cloud), the core-native replacement built on the Salesforce platform. This eliminates the managed package overhead and namespace-specific governor limit issues. The key architectural shift: we move from SBQQ custom objects to core-native platform objects, lose JavaScript Quote Calculator Plugins in favor of the native pricing engine, and migrate approval workflows from SBAA to built-in platform approvals. Important nuance: existing SBQQ customers can still renew and add licenses — the end-of-sale only blocks new customers with no prior contract.”
Follow-up: What about existing SBQQ customers who want to extend their implementation? Would you recommend the same path?
Q1.4: OmniStudio Without Licensing
Judge: “You architected the custom onboarding wizard using OmniStudio’s OmniScripts. However, this customer is on Sales Cloud Enterprise Edition with no Industry Cloud or standalone OmniStudio licenses. Your solution introduces an unjustified licensing dependency. How do you revise?”
What they’re testing: Awareness of OmniStudio licensing prerequisites and the ability to deliver equivalent functionality using standard platform features.
Model answer: “You are correct. Recommending OmniStudio without an existing Industry Cloud or OmniStudio license adds unnecessary cost and fails the ROI check. I will revise to use standard Screen Flows, which are included in their existing licenses and provide admin-maintainable guided experiences. If the UI requirements for the onboarding wizard exceed standard Flow capabilities (complex conditional rendering, advanced data transformations), I will embed custom Lightning Web Components within the Screen Flow to handle the complex UI while maintaining Flow as the orchestrator.”
Follow-up: What specific OmniStudio capabilities would be impossible to replicate with Screen Flows plus embedded LWCs?
Q1.5: Deprecated Automation Tools
Judge: “Your automation strategy shows a new Process Builder that fires on Opportunity stage changes. Process Builder creation was blocked in Summer ‘23 (end-of-support December 31, 2025). You also have two AppExchange managed packages and a custom Apex trigger on the same object with no execution order analysis. Walk me through how you fix this.”
What they’re testing: Knowledge of deprecated automation tools and the risk of mixing multiple automation types on the same object without execution order analysis.
Model answer: “I have two issues to address. First, Process Builder is deprecated — creation was blocked in Summer ‘23, and end-of-support was December 31, 2025. I will replace it with a Record-Triggered Flow. Second, having multiple automation types (Flow, Apex trigger, managed package triggers) on the same object without execution order analysis creates unpredictable behavior. The fix: consolidate all custom logic into a single master Record-Triggered Flow per trigger event (one before-save, one after-save) with subflow routing. Document the execution order chain with the managed package triggers, and coordinate with package vendors on their trigger behavior to identify potential conflicts.”
Follow-up: How do you handle the managed package triggers that you cannot control or consolidate?
Type 2: Missed - “You Haven’t Addressed…”
The judge is pointing out a gap in your design.
Q2.1: Order of Execution Not Addressed
Judge: “In your architecture for the Case object, you recommended a mix of after-save Flows, Apex triggers, and kept existing workflow field updates, but you completely missed addressing the order of execution. How does this specific combination impact system performance and your governor limit budget?”
What they’re testing: Order of execution mastery, specifically the workflow re-execution trap where triggers fire twice when workflow field updates modify a record.
Model answer: “You are correct, omitting the order of execution analysis is a critical miss. When workflow field updates modify a record, Salesforce re-runs before and after Apex triggers one additional time, consuming governor limits a second time. This re-execution does NOT re-run validation rules or before-save flows. This means triggers fire twice, doubling their CPU and SOQL consumption. To fix this and stabilize the execution order, I will consolidate the legacy workflow rules into the Flow or Apex triggers, as workflows are deprecated and mixing them creates unpredictable execution chains. The target state is one before-save Flow and one after-save Flow per object with all logic consolidated.”
Follow-up: If migrating the workflow rules would take 3 sprints, what interim mitigation do you implement?
Q2.2: Agentforce Evaluation Missing
Judge: “For the telecom company handling 50,000 routine cases per month, you proposed standard Screen Flows and traditional Einstein Bots. Review boards now expect AI agents to be considered. Why did you miss evaluating Agentforce, and how would deploying it change your architecture?”
What they’re testing: Modern AI capabilities awareness. Failing to evaluate Agentforce for high-volume service deflection signals outdated knowledge.
Model answer: “I acknowledge the miss. Agentforce must be evaluated for high-volume customer service deflection. I will revise to recommend an Agentforce Service Agent, which uses the Atlas reasoning engine’s ReAct loop to interpret natural language intent rather than following rigid decision trees. By reusing our existing Flows as agent actions for billing and outage inquiries, we can target a 30-50% deflection rate for mature implementations with well-curated knowledge and RAG sources (ranges cited by Salesforce and early adopters vary; commit to a range you can defend). At $2 per conversation compared to $12 per-case human agent cost, this provides significant ROI. The architectural additions: Data 360 for RAG grounding, Einstein Trust Layer for PII masking and zero-retention model hosting, a dedicated agent user with least-privilege permissions, and statistical testing via Testing Center instead of binary pass/fail.”
Follow-up: What is the minimum viable architecture if the customer cannot afford Data 360 alongside Agentforce?
Q2.3: AppExchange Exit Strategy Missing
Judge: “You recommended three AppExchange packages but have not mentioned what happens if any of these vendors raises prices, is acquired, or discontinues the product. What is your exit strategy?”
What they’re testing: Vendor dependency risk management. Every buy decision at the CTA board requires a documented exit strategy.
Model answer: “You are right to call this out. Every managed package creates vendor lock-in, and an exit strategy is mandatory. My exit plan for each package includes: (1) Data portability: ensure all stored data can be exported in standard formats via APIs. (2) Process independence: document business processes independently of the tool so they can be rebuilt on standard platform features. (3) Facade pattern: where possible, use standard Salesforce objects as the integration layer rather than package-specific custom objects. (4) Contractual protections: negotiate data export rights and reasonable notice periods in the contract. (5) Pre-estimated migration effort: for each package, document the estimated effort to migrate to a native or alternative solution.”
Follow-up: For the CPQ package specifically, how long would a realistic migration take and what is the blast radius?
Q2.4: CPQ Pricing Waterfall Misconfigured
Judge: “Your CPQ solution shows partner channel discounts stacking on top of volume discounts, but you missed configuring the pricing waterfall to apply channel discounts against the List Price as the business requires. How do you customize this?”
What they’re testing: CPQ pricing waterfall depth and the ability to distinguish declarative waterfall customization from code-level extensions.
Model answer: “I missed addressing this pricing requirement. Legacy Salesforce CPQ’s pricing waterfall calculates roughly: List Price > Contracted Price > Special Price > Regular Price (after volume and tiered discounts from Discount Schedules) > Customer Price (after partner and distributor discounts from Additional Discount, Partner Discount, and Distributor Discount fields) > Net Unit Price. The business requirement here is to apply channel discounts off List Price rather than Regular Price. The declarative options are: (a) remodel the Discount Schedule assignments so the channel-specific schedule uses Price Book Entry (list) as the discount base rather than Regular Price, or (b) use a Price Rule that evaluates at the Calculate price action and writes the computed discounted value back to the Quote Line’s Customer Price or a custom discount field before the standard waterfall sums the remaining components. If neither declarative path is expressive enough, the code path is a custom Quote Calculator Plugin (QCP) JavaScript class that intercepts the Calculate stage and reorders the discount application — but that carries the 131,072-character QCP limit and the maintenance cost of custom JavaScript. For greenfield implementations I’d flag that legacy CPQ is end-of-sale as of March 2025 and steer toward Agentforce Revenue Management, whose pricing engine exposes the waterfall as declarative Pricing Procedures that can be reordered without code.”
Follow-up: What if a different partner tier needs channel discounts applied at a different point in the waterfall? How does your answer change?
Q2.5: Headless Commerce Not Evaluated
Judge: “The requirements mention a mobile-first B2C customer experience, but you have proposed a standard SFRA storefront without evaluating headless commerce. Why did you miss this, and when is headless the right choice?”
What they’re testing: Commerce architecture breadth, specifically knowledge of when headless/composable commerce is architecturally justified vs. standard storefronts.
Model answer: “I should have evaluated headless commerce for the mobile-first requirement. Composable Storefront (PWA Kit) is justified when: sub-second performance is required across multiple channels (web, mobile app, kiosk), the frontend team has React expertise, and the business needs omnichannel delivery. For this mobile-first scenario, PWA Kit provides server-side rendering, edge caching, and optimized mobile performance via React and SCAPI. SFRA is the right choice when standard web-only performance is acceptable and speed-to-market using templates is the priority. I will revise to recommend headless with a clear ROI justification for the additional frontend complexity.”
Follow-up: How does going headless change your integration architecture and testing strategy?
Type 3: Suboptimal - “Have You Considered…?”
The judge is suggesting a potentially better approach.
Q3.1: Apex for Simple Routing Logic
Judge: “You have written 200 lines of Apex to route Cases to different queues based on 8 field conditions. Since the logic only involves checking fields and updating the owner without complex data transformations, this is suboptimal. Why did you choose Apex over Flow?”
What they’re testing: Adherence to the declarative-first principle. Field-based routing without complex transformations is Flow territory.
Model answer: “You are correct. Using Apex for simple field-based routing is an anti-pattern when a declarative solution handles it well. I will revise to a Record-Triggered Flow with Decision elements for the 8 conditions. This keeps the logic admin-maintainable, avoids unnecessary developer dependency, and aligns with the declarative-first principle. The Flow Decision element handles multi-condition routing cleanly with OR/AND logic. I would only flip to Apex if the routing required complex geo-spatial calculations or cross-referencing against a collection exceeding 50,000 territory records where Maps and Sets provide performance advantages.”
Follow-up: At what condition complexity would you shift back to Apex? Is there a number of conditions where Flow becomes unwieldy?
Q3.2: Custom Portal vs Experience Cloud
Judge: “You proposed a custom portal built on Heroku for the partner community. Have you considered that Experience Cloud provides native authentication, sharing model integration, and CRM data access without custom integration?”
What they’re testing: Platform-native evaluation discipline. Experience Cloud should be evaluated before any custom portal build.
Model answer: “I acknowledge that Heroku is suboptimal for this requirement. I will revise to Salesforce Experience Cloud with LWR templates. It provides: native Salesforce authentication and SSO integration, native sharing model (Sharing Sets for external users), pre-built Lightning components, CRM data access without custom API integration, and portal analytics. Building on Heroku means rebuilding all of this from scratch, plus Year 1 development costs and compounding technical debt over 3-5 years. Additionally, Heroku Enterprise contracts are no longer offered to new customers as of February 2026 (Heroku moved to sustaining engineering), though pay-as-you-go Heroku remains available. For a regulated partner portal that needs long-term enterprise support, investing new workloads in Heroku is not recommended regardless. A custom build should only be pursued if the portal represents a core competitive advantage that cannot be met by standard capabilities.”
Follow-up: Are there specific Experience Cloud limitations that would push you back toward a custom build?
Q3.3: Custom LWC vs OmniStudio
Judge: “For the complex, multi-step insurance quoting wizard, you recommended building custom Lightning Web Components. Given the customer already has Industry Cloud licenses, this is suboptimal. What native toolkit should you have used?”
What they’re testing: OmniStudio awareness when Industry Cloud licensing is available.
Model answer: “Since the customer holds an Industry Cloud license, recommending custom LWC is suboptimal as it requires heavy developer resources for something the platform already provides. I will revise to OmniStudio: OmniScripts for the multi-step guided UI with conditional branching, DataRaptors for data transformations, and Integration Procedures for backend API orchestration. This industry-oriented, low-code toolkit reduces build time by using pre-built templates and keeps the experience admin-maintainable. Flip condition: if the customer does NOT have OmniStudio licensing, then Screen Flows with embedded LWCs for complex UI segments is the correct approach.”
Follow-up: What happens when the OmniStudio license expires and the budget does not support renewal?
Q3.4: MuleSoft for Simple API
Judge: “You architected a MuleSoft integration solely to make a simple GET request to an external tax calculation API that already provides an OpenAPI specification. This is massive over-engineering. How can you fulfill this natively?”
What they’re testing: Right-sizing integration tooling. External Services handles simple REST APIs without middleware or custom code.
Model answer: “You are right. MuleSoft Anypoint, which carries high license cost and is designed for complex enterprise API management, is over-engineering for a single REST API callout. I will revise to standard External Services. By registering the API’s OpenAPI spec, we auto-generate typed invocable actions callable from Flow Builder, eliminating the need for integration middleware or custom Apex. Named Credentials handle authentication. MuleSoft becomes justified when the number of integrated systems exceeds 5 or when complex transformation, orchestration, and centralized API governance are required.”
Follow-up: What if the tax API lacks an OpenAPI spec and requires complex retry logic with exponential backoff?
Q3.5: Custom Approvals vs Flow Orchestration
Judge: “You built a custom multi-step approval routing engine in Apex for quote approvals that spans multiple users and departments. Have you evaluated Flow Orchestration, which handles this natively?”
What they’re testing: Awareness of Flow Orchestration for multi-step, multi-user, long-running approval processes.
Model answer: “I should have evaluated Flow Orchestration before building custom Apex. Flow Orchestration handles long-running, multi-step business processes spanning multiple users, multiple days, and multiple stages with parallel and sequential step execution. For this quote approval spanning multiple departments: legal reviews in parallel with finance approval, then sequential VP sign-off. This is exactly what Orchestration is designed for. Custom Apex creates unnecessary maintenance burden and developer dependency. Flip condition: if the approval logic requires complex conditional routing that exceeds Orchestration’s capabilities, or integration with external approval systems, Apex may be justified.”
Follow-up: What specific capabilities does Flow Orchestration lack that would push you to Apex for approvals?
Q3.6: Custom Pricing Engine vs Revenue Cloud
Judge: “You are proposing a custom pricing engine built in Apex for the customer’s quoting needs. The customer has 500 configurable products with nested bundles and engineering constraints. Have you evaluated Revenue Cloud?”
What they’re testing: Awareness of platform products (Revenue Cloud/CPQ) vs. reinventing the wheel with custom code.
Model answer: “Building a custom pricing engine is suboptimal when the platform provides purpose-built solutions. For 500 configurable products with nested bundles and engineering constraints, Agentforce Revenue Management (formerly Revenue Cloud) provides: native product configuration with bundles and options, pricing waterfall with volume/tiered discounts, product rules for engineering constraint validation, price rules for surcharge calculations, and approval workflows. Custom Apex means rebuilding this entire pricing architecture from scratch, creating massive technical debt. The only justification for custom would be if the pricing logic is so unique that it represents a core competitive differentiator that no platform or ISV solution can address.”
Follow-up: What if the customer already has a custom pricing engine in production? Do you still recommend migration?
Type 4: Rationale Missing - “WHY Did You Choose…?”
The judge wants to hear the reasoning behind a correct decision.
Q4.1: Flow vs Apex Decision Framework
Judge: “Walk me through your Flow versus Apex decision framework. How do you decide which tool to use for each automation requirement?”
What they’re testing: Whether the candidate has a consistent, articulable framework rather than making ad-hoc tool selections.
Model answer: “I evaluate each automation against seven criteria: (1) Complexity: can the logic be expressed in Flow Decision/Assignment elements without nested loops with Maps? (2) Volume: is the record count under 50,000? (3) Transaction control: does it need Database.setSavepoint() and rollback()? (4) Callout complexity: does it need retry logic or circuit breakers? (5) Testability: does the logic require rigorous unit testing beyond the 75% platform minimum (architects target 85%+ as best practice)? (6) Maintainability: should admins modify this without developers? (7) Performance: will Flow CPU time suffice or does it need optimized Apex collections? If criteria 1-2-6 point to Flow and 3-4-5-7 are not factors, use Flow. For complex logic needed by Flow, use the Invocable Action Bridge pattern: Apex @InvocableMethod exposed to Flow as a declarative element. Flip condition: if volume exceeds 50,000 records, I flip to Batch Apex regardless of other criteria.”
Follow-up: Give me a specific example where you would use the Invocable Action Bridge pattern instead of pure Flow or pure Apex.
Q4.2: Build vs Buy TCO Justification
Judge: “You chose to build a custom document generation solution instead of purchasing an AppExchange package. Walk me through the full TCO justification over 5 years.”
What they’re testing: Build-vs-buy TCO analysis rigor. Whether the candidate can justify with numbers, not just assertions.
Model answer: “I would NOT typically recommend custom for document generation because it is commoditized capability, not a competitive differentiator. But if forced to justify: Build TCO includes Year 1 development (40-60% of total), plus Years 2-5 compounding at 15-20% annually for maintenance, bug fixes, developer turnover, and feature requests. The 3-year crossover point is where custom TCO exceeds buy TCO. Buy TCO: predictable annual license fee, vendor handles upgrades and platform compatibility, includes compliance audit trail. The ‘we have developers’ argument ignores opportunity cost: those developers could build differentiating features. My recommendation: buy the AppExchange package with a documented exit strategy, and redirect developer capacity to competitive advantage features.”
Follow-up: What if the customer’s document generation requirements are truly unique and no AppExchange solution covers more than 60% of requirements?
Q4.3: LWC vs Aura Migration Strategy
Judge: “Why did you choose LWC over Aura for the new components in this solution? And why are you keeping the existing Aura components?”
What they’re testing: Technology direction awareness combined with pragmatic migration judgment.
Model answer: “For the new onboarding wizard, I selected LWC because: it is built on modern web standards (Shadow DOM, ES Modules) with superior performance, Salesforce actively invests in LWC while Aura receives maintenance-only updates, and the developer talent pool increasingly expects LWC. However, I explicitly chose NOT to migrate the stable billing dashboard Aura components because I follow the principle of never migrating for migration’s sake. The stable Aura components deliver their required functionality without issues. Rewriting them in LWC would cost significant developer capacity while delivering zero new business value. We will opportunistically migrate when those components require significant new feature development.”
Follow-up: What if the Aura components need a minor bug fix? Does that trigger migration?
Q4.4: Agentforce vs Einstein Bots
Judge: “You recommended Agentforce instead of Einstein Bots for the customer’s service desk. Walk me through the cost comparison and the capability gap that justifies Agentforce.”
What they’re testing: Whether the candidate corrects the common misconception that Einstein Bots are free with Service Cloud, can quantify the ROI of an AI solution, and can articulate the specific capability gap that justifies Agentforce’s cost.
Model answer: “First, I’ll correct a common misconception baked into the question premise: Einstein Bots are NOT included with Service Cloud. They are a paid add-on — roughly $75/user/month on Enterprise Edition for messaging session bots, with Unlimited Edition including a limited allocation. So the real comparison is Agentforce against a paid Einstein Bots add-on, not against a free built-in. With that corrected, the capability gap drives the decision: the telecom scenario involves customers describing complex billing and outage issues in natural language, which requires multi-step reasoning. Einstein Bots use rigid, rule-based dialog trees with limited NLU, making them effective for simple structured FAQs but ineffective for ambiguous, complex problems. Agentforce uses the Atlas Reasoning Engine’s ReAct loop to dynamically plan, retrieve data via Data 360, and execute actions autonomously. At $2 per Agentforce conversation deflecting cases that currently cost $12 per human agent interaction, the ROI is 5-7x even after netting out the Einstein Bots cost we would otherwise be paying. Flip condition: if the requirement were purely simple, structured queries with low volume, Einstein Bots at the lower add-on price may be more cost-effective than Agentforce conversations.”
Follow-up: What is the minimum deflection rate needed to break even on the Agentforce investment, assuming you are also decommissioning an existing Einstein Bots deployment?
Q4.5: B2B Commerce vs Custom Storefront
Judge: “Why did you recommend B2B Commerce instead of building a custom storefront on Experience Cloud for the dealer portal?”
What they’re testing: Commerce architecture selection rationale with platform-native product awareness.
Model answer: “B2B Commerce gives us the commerce-specific capabilities out of the box that a custom Experience Cloud storefront would force us to build and maintain. Core capabilities we get natively: a product catalog with category hierarchy, entitlement-based catalog visibility (so each dealer sees only their contracted product lines), configurable bundles tied to Product options, buyer account and buyer group modeling for B2B pricing tiers, account-specific price books, contract pricing, negotiated discounts, stored payment methods, quote-to-order workflows, order history, re-order and reorder-from-list, checkout with tax/shipping integration hooks, and B2B-specific UX patterns (bulk order CSV upload, quick order pad, account hierarchies). On top of that, B2B Commerce is Experience Cloud under the hood — so we still get Salesforce authentication, sharing model, CRM object access, and LWR/LWC customization for branded experiences. Building this on a raw Experience Cloud site means rebuilding each of those capabilities in custom LWCs plus extensive data modeling, which is 9-18 months of development and a compounding maintenance burden that delivers nothing dealers can’t get from a platform product. The flip condition would be a storefront with extreme UX uniqueness that B2B Commerce templates cannot absorb — and even then I’d evaluate Composable Storefront (PWA Kit) on top of B2B Commerce APIs before going custom. For standard dealer portals with configured products and contract pricing, B2B Commerce is strictly the right answer.”
Follow-up: How does the B2B Commerce data model interact with Revenue Cloud if dealers also need configurable quotes with engineering constraints?
Q4.6: Agentforce Pricing Model Analysis
Judge: “You chose Flex Credits over per-conversation pricing for Agentforce. Walk me through the analysis.”
What they’re testing: Quantitative pricing model analysis for AI solutions.
Model answer: “The choice depends on the actions-per-conversation ratio. Conversations model: flat $2 per completed conversation regardless of actions. Flex Credits: 20 credits per action at $500 per 100K credits ($0.10/action). Breakeven calculation: $2/conversation equals 20 actions at $0.10 each. If the average conversation uses fewer than 20 actions, Flex Credits is cheaper. Our analysis shows the average service interaction uses 3-5 actions (query customer, check history, update record, send email), so Flex Credits costs approximately $0.30-$0.50 per conversation vs. $2.00. The org-wide constraint is critical: you cannot combine models in the same org. If we later add a sales agent with higher action counts, the Flex Credits advantage may diminish. This is a pricing model lock-in decision that must account for future use cases.”
Follow-up: What happens when you need to switch pricing models? Can you change mid-contract?
Type 5: Cascading - “If You Change X, What Happens to Y?”
The judge is testing whether you can trace impacts across domains.
Q5.1: Flow to Apex Migration Cascade
Judge: “The team has decided to move the pricing logic from a Record-Triggered Flow to Apex because Flow cannot handle the volume. Walk me through the cascading impact on team structure, development lifecycle, and order of execution.”
What they’re testing: Cross-domain cascade analysis when shifting from declarative to programmatic.
Model answer: “Migrating from Flow to Apex triggers a cascade across multiple domains. First, the maintenance burden shifts from the admin team to the developer team, directly impacting staffing model and operational agility. Second, governance and CI/CD: we must now implement automated unit testing (@isTest) with 75% minimum coverage (platform requirement; target 85%+ as architect best practice) and enforce code coverage gates in our deployment pipeline, whereas Flow testing was largely manual. Third, order of execution: Apex triggers and Batch jobs execute at different points than before-save/after-save flows, requiring re-evaluation of any overlapping declarative automation. Fourth, transaction context shifts: Batch Apex provides separate governor limit allocations per batch execution, but we must implement explicit bulkification and Database.Stateful for cross-batch state. The flip condition that drove this decision was exceeding 50,000 records.”
Follow-up: How do you manage the transition period where both the old Flow and new Apex code exist? What is the cutover strategy?
Q5.2: CPQ Vendor EOL Blast Radius
Judge: “The customer’s CPQ vendor just announced end-of-life in 18 months. They are giving you 6 months notice. Trace the cascading architectural blast radius of removing this deeply embedded package.”
What they’re testing: Full cross-domain impact analysis for vendor exit, spanning data, integration, security, and dev lifecycle.
Model answer: “The blast radius extends across every domain: Data Architecture (D3): must migrate data from ~30 vendor-specific custom objects to standard or replacement objects, requiring ETL planning, data mapping, and historical data preservation. Integration (D5): any integrations pointing to package-specific APIs, webhooks, or objects must be re-routed to the replacement solution. Security (D2): sharing rules, FLS settings, and permission sets on package objects must be rebuilt on replacement objects. Dev Lifecycle (D6): the regression test suite covering the quote-to-cash process must be completely rebuilt. Solution Architecture (D4): evaluate Agentforce Revenue Management as the replacement, assess functional fit via vendor scorecard, and plan the phased migration starting with the highest-volume product families. Execute with a bridge contract to extend support during the transition.”
Follow-up: How do you prioritize which product families to migrate first, and what is the minimum viable migration?
Q5.3: Agentforce Data Architecture Impact
Judge: “You are adding Agentforce to the existing architecture. How does introducing AI agents cascade across your data architecture, security model, and testing strategy?”
What they’re testing: Cross-domain cascade when adding an AI capability layer to an existing implementation.
Model answer: “Adding Agentforce creates cascades across three domains. Data Architecture (D3): Data 360 becomes a dependency for advanced RAG grounding, introducing data ingestion pipelines, identity resolution costs (100,000 credits per million rows), and unified customer profile creation. Security (D2): must create a dedicated Agent User with least-privilege permission sets; Agentforce respects the running user’s sharing model, so FLS misconfigurations cause silent agent failures rather than visible errors. Must explicitly use ‘with sharing’ in all Apex Agent Actions. The Trust Layer masks PII before LLM processing and enforces zero-retention contracts with model vendors. Testing (D6): shifts from binary pass/fail deterministic testing to statistical validation. The Testing Center handles batch simulation of hundreds of interactions. Production requires an Agent Health dashboard monitoring deflection vs. escalation rates. Existing Flows and Apex must be explicitly exposed as Agent Actions mapped to specific Topics (the platform enforces hard limits of 15 topics per agent and 15 actions per topic; check the current Agentforce Considerations help article for org-wide agent version limits as those have evolved across releases).”
Follow-up: What is the cost of the Data 360 dependency? How does identity resolution pricing impact the business case?
Q5.4: Field Service Adoption Cascade
Judge: “The customer wants to replace their custom scheduling solution with Salesforce Field Service. Walk me through the cascading impact on data model, licensing, integration, and TCO.”
What they’re testing: Full platform product adoption cascade across all domains.
Model answer: “Replacing custom scheduling with Field Service cascades across all domains. Data Model (D3): deprecate custom scheduling objects and migrate data to standard Field Service objects (Work Orders, Service Appointments, Service Resources). Licensing (D1): Field Service Lightning add-on licenses replace free custom objects, increasing Year 1 operating costs. Integration (D5): existing integrations referencing custom objects must be re-routed to standard Field Service objects; mobile field agent connectivity requires Salesforce Field Service mobile app configuration. Security (D2): field technician profiles need specific permission sets; mobile offline access requires separate security consideration for cached data. Dev Lifecycle (D6): the regression test suite must be rebuilt for the new object model. TCO improves over 3-5 years by eliminating compounding technical debt: no more custom bug fixes, feature requests are handled by Salesforce releases, and the mobile app provides built-in scheduling optimization.”
Follow-up: What is the migration strategy for historical work order data in the custom objects?
Q5.5: Headless Commerce Cascade
Judge: “You are swapping from the standard B2B Commerce storefront to a headless architecture mid-project. Walk me through what changes across the architecture.”
What they’re testing: Commerce architecture cascade when changing the frontend strategy.
Model answer: “Swapping to headless cascades across multiple domains. Solution Architecture (D4): the frontend shifts from LWR (Lightning Web Runtime) on Salesforce to a React-based PWA Kit running on its own Node.js infrastructure, requiring separate hosting and CDN configuration. Integration (D5): data access shifts from native Salesforce component rendering to API-first architecture using SCAPI (Shopper APIs), requiring explicit API design and rate limit management. Dev Lifecycle (D6): the team now needs React/Node.js expertise alongside Salesforce skills, changing hiring and training requirements. The CI/CD pipeline must handle both the Salesforce backend and the Node.js frontend deployments. System Architecture (D1): performance improves with edge caching and server-side rendering but at the cost of infrastructure complexity. Communication (D7): the solution architecture diagram must be updated to show the decoupled frontend-backend relationship.”
Follow-up: How does this change the testing strategy? Can you still use Salesforce-native testing tools?
Q5.6: Push Upgrade Governance
Judge: “An AppExchange document generation package received a push upgrade that broke your custom Apex trigger on the same object. Walk me through the governance cascade.”
What they’re testing: Push upgrade governance and the cascading impact of managed package changes on custom automation.
Model answer: “Push upgrades are vendor-initiated and can introduce new triggers, modify existing behavior, or change object dependencies without explicit customer approval. The cascade: first, the new or modified package trigger changed the effective execution order among all triggers on the object, creating timing-dependent conflicts with our custom trigger. Second, since trigger execution order across namespaces is not guaranteed, our custom trigger’s assumptions about field values may no longer hold. Governance fix: (1) Implement a sandbox testing mandate for all push upgrades before they reach production. (2) Maintain an automated regression test suite covering the critical paths that interact with the package. (3) Coordinate with the vendor on their release schedule and review release notes for trigger changes. (4) Consider consolidating custom logic into a single trigger handler pattern to reduce the surface area of execution order conflicts.”
Follow-up: Can you block push upgrades? What are the trade-offs of opting out?
Q5.7: Data 360 Removal Impact
Judge: “The customer has decided not to purchase Data 360. Your architecture relies on Agentforce with RAG grounding. How does this decision cascade through the solution?”
What they’re testing: Architecture adaptation when a dependency is removed, specifically the impact on AI agent capability.
Model answer: “Removing Data 360 cascades through the Agentforce architecture significantly. RAG grounding degrades: without Data 360, the agent cannot perform vector search across unstructured content (PDFs, chat transcripts, emails). It is limited to direct CRM SOQL queries and Knowledge articles. Cross-system context is lost: the unified customer profile from external systems (commerce, marketing, ERP) is unavailable, meaning the agent cannot see the complete customer picture. Mitigation: (1) Maximize Knowledge article quality and coverage as the primary grounding source. (2) Use Flow-based actions that aggregate data from multiple objects within CRM to simulate broader context. (3) Set explicit escalation rules for any inquiry requiring cross-system data. (4) Document this as a capability limitation in the solution and plan for Data 360 addition as a Phase 2 enhancement when budget allows. The deflection rate expectation must be revised downward — commit to a conservative target (e.g., 15-25%) until Data 360 grounding is added.”
Follow-up: What is the minimum Data 360 configuration that would restore most of the RAG capability?
Q5.8: Revenue Cloud Migration Cascade
Judge: “The customer is migrating from legacy SBQQ CPQ to Agentforce Revenue Management. Walk me through the full migration cascade across data model, pricing logic, approval workflows, and governor limits.”
What they’re testing: Revenue Cloud migration architecture covering all impacted architectural layers.
Model answer: “The migration cascades across every architectural layer. Data Model: shifts from the SBQQ namespace custom objects (SBQQ__Quote__c, SBQQ__QuoteLine__c, ~30 custom objects) to core-native platform objects using Products, Offers, and Prices. All data must be ETL’d with careful ID mapping. Pricing Logic: JavaScript Quote Calculator Plugins (QCP, 131,072-character limit) must be completely rewritten in the Revenue Management native pricing engine. Price Rules and Product Rules must be re-implemented in the new architecture. Approval Workflows: Advanced Approvals (SBAA) must be migrated to built-in platform approval processes or Flow Orchestration. Governor Limits: we lose the certified managed package’s separate SOQL (100) and DML (150) allocations per namespace, but we reduce pressure on the shared CPU time and heap that the heavy SBQQ package consumed. Integration: any integrations referencing SBQQ objects must be re-mapped to the new data model. This is a 6-12 month migration depending on complexity.”
Follow-up: Can the two systems run in parallel during migration? What is the coexistence strategy?
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.