Domain Grilling: D7 Communication
Communication is independently scored throughout the entire presentation and Q&A. There is no separate “communication section.” Judges evaluate whether candidates articulate benefits and limitations clearly, use visualization tools effectively, and handle unexpected roadblocks with composure. This domain tests consulting acumen as much as technical knowledge.
Type 1: Invalid - “Your Solution Won’t Work”
Q1.1: Diagram Legends and Middleware Layer Requirements
Judge: “I am looking at your System Landscape diagram, and I cannot tell what these green arrows from Salesforce directly to the legacy ERP mean. There is no legend, and no labels on the lines. Are you really proposing a direct point-to-point integration from Salesforce to an on-premise ERP without middleware? That won’t work for enterprise security.”
What they’re testing: Whether you know that legends and data flow labels are mandatory on enterprise diagrams, and that missing an explicit integration layer (MuleSoft/ESB) in a complex multi-system scenario is a hallmark of a failing artifact. Also testing whether you will stubbornly defend a broken pattern or correct it.
Model answer: “You are absolutely correct, and I apologize for the lack of clarity. My diagram has two distinct flaws: it is missing the mandatory legend and labels, and it shows a point-to-point integration pattern that is not defensible for this scenario’s multi-system, transformation-heavy, orchestrated integration needs.
Middleware is always a ‘depends’ decision. My criteria: number of integrated systems, transformation complexity, orchestration requirements, reusability, centralized governance, error-handling patterns, and the integration roadmap. For single-integration scenarios with no other systems on the roadmap and no transformation complexity, direct Apex callouts with Named Credentials are often the right answer. This scenario is the opposite: multiple external systems, heterogeneous protocols, transformation needs, and enterprise security governance. Given those facts, middleware is justified.
To correct the diagram immediately, I would introduce an explicit middleware layer, such as MuleSoft or an ESB, sitting between Salesforce and the legacy ERP and the other integrated systems. I will route the integrations requiring transformation or orchestration through this middleware to ensure proper circuit breaking, protocol translation, and enterprise security. For any remaining single-system, no-transformation callouts I would still evaluate them case by case and keep them direct where they qualify.
To fix the visualization gap, I would add a legend to clarify my color coding. For example, green denoting user channels, blue for Salesforce, and orange for the new middleware layer. For those specific arrows connecting Salesforce to the ERP through the new ESB, I would label them to show the data flow direction, the timing, and the protocol, such as ‘Bidirectional, Async, REST API.’
Changing this to a middleware-led approach cascades into my Integration Architecture. It means my error-handling strategy will now rely on the ESB’s dead-letter queues rather than custom Apex retry logic inside Salesforce. Thank you for catching that; the introduction of the ESB makes the architecture much more resilient.”
Follow-up: “Now that you’ve correctly added MuleSoft to your landscape, how does this change your licensing and cost assumptions for the project?”
Q1.2: Solution Dumping Anti-pattern and Business-first Narrative
Judge: “You’ve spent the last three minutes explaining the deep technical mechanics of the JWT Bearer flow and your custom Lightning Web Component architecture, but I don’t understand how this addresses the client’s actual problem. Why are we building this, and why couldn’t we just use a standard feature?”
What they’re testing: Whether you can recognize you are ‘solution dumping’ (describing technical architecture without tying it to a business requirement) and pivot from technical jargon to a business-first narrative anchored in scenario requirements.
Model answer: “You make a very fair point. I dove straight into the technical execution and committed a solution dump without anchoring my design to the business context. Let me step back and reframe this decision using a business-first approach.
The critical requirement driving this architecture is the client’s need for partners to have a sub-two-second page load time while seamlessly viewing real-time inventory from the external ERP without a secondary login. I chose the custom LWC and the JWT Bearer flow specifically because it solves this exact business problem.
I considered using standard declarative features, such as a standard External Object connection or a basic Flow. However, the limitation of the declarative approach is that it cannot support the highly customized, dynamic UI requirements and the strict performance SLAs requested by the partner network. By using a custom LWC integrated via a JWT Server-to-Server flow, we trade development simplicity for a highly performant, seamless user experience that directly protects partner adoption.
Using the trade-off formula: what I gave up is admin maintainability and faster initial delivery. The condition that would change my mind is if the partner network drops below 50 users, at which point standard External Objects would be adequate. The alternative I rejected was a Visualforce page, which would meet the functional requirement but cannot match LWC performance on modern browsers.
Going forward, I will make sure to state the business ‘why’ before diving into the technical ‘how.’ That is one of the 10 Commandments of CTA presentation: always lead with the business requirement, then justify the technology.”
Follow-up: “Given that you are prioritizing performance over development simplicity, what governance mechanisms do you have in place to ensure this custom code doesn’t become technical debt?”
Q1.3: Cross-domain Contradiction Between Data Model and Security Model
Judge: “That won’t work. On your sharing slide, you stated you are using criteria-based sharing rules to open up visibility for the ‘Invoice’ object. However, looking back at your Data Model, you made ‘Invoice’ the detail side of a Master-Detail relationship with the ‘Account’. You cannot put sharing rules on a detail object.”
What they’re testing: Whether you can handle an unexpected roadblock where your data model directly contradicts your security model. Testing your ability to acknowledge the impossibility, pick a lane (change the relationship or the sharing), and verbally trace the cascading impact chain.
Model answer: “You are completely right; that design is fundamentally invalid. I contradicted my own architecture across domains. Because a detail object inherits its sharing rules directly from the master, criteria-based sharing rules cannot be applied to the Invoice object in my current ERD. I cannot defend that broken approach.
To correct this on the spot, I need to evaluate which requirement is more critical: the strict ownership hierarchy or the specific invoice sharing. Given the scenario requires regional managers to only see invoices over $10,000 regardless of who owns the Account, the criteria-based sharing requirement is the priority.
Therefore, I will adapt my Data Model. I am changing the relationship between Account and Invoice from a Master-Detail to a Lookup relationship.
Changing this relationship has cascading impacts across three areas. First, it fixes my Sharing Model, allowing me to set the Invoice OWD to Private and apply the criteria-based sharing rule for regional managers. Second, it breaks any roll-up summary fields I assumed I could use on the Account. To mitigate that new gap, I will introduce a Record-Triggered Flow to calculate the Total Invoice Amount on the Account. Third, it changes my delete behavior: without cascade delete from the Master-Detail, I need to handle orphaned invoice cleanup through a scheduled batch process.
Using the Acknowledge-Reason-Alternatives-Concede framework: I acknowledge the flaw is real, the reason for the fix is that sharing requirements outweigh the convenience of Master-Detail, the alternative I considered was keeping Master-Detail and using Apex managed sharing instead of criteria-based rules, and I concede that the Flow-based rollup introduces slight calculation latency. Thank you for catching that contradiction.”
Follow-up: “Since you are now using a Flow instead of a Roll-Up Summary, what happens to that calculation if we load 5 million historical invoices during the data migration?”
Q1.4: Scripted Delivery Exposed by Scenario-specific Constraints
Judge: “You have stated three times that a ‘Single Org is enterprise best practice’ and that’s why you are consolidating. That won’t work here. The scenario explicitly states the European business unit is legally forbidden from sharing IT infrastructure or databases with the North American unit. Your single org strategy violates their compliance laws.”
What they’re testing: Whether you are using a memorized script and relying on generic ‘enterprise best practice’ buzzwords instead of reading the actual scenario. Also testing composure: will you get defensive and double down, or accept the constraint and pivot gracefully?
Model answer: “You are exactly right, and I appreciate you highlighting that strict legal constraint. I made the mistake of leaning on a generic ‘enterprise best practice’ and delivering a scripted assumption rather than designing for the specific regulatory constraints of this scenario. A single org is completely invalid given those data residency laws.
I am immediately pivoting my Org Strategy to a Multi-Org architecture. We will provision a distinct Salesforce org for the European business unit to ensure complete physical separation of the database and IT infrastructure, meeting their strict compliance requirements.
This pivot heavily cascades across my entire architecture. First, my System Landscape now needs to show two separate Salesforce Orgs with distinct cloud boundaries on the diagram. Second, my Integration Architecture will need to use our ESB or Salesforce-to-Salesforce patterns to selectively sync only legally permissible aggregated data between the two orgs. Third, my Identity and SSO flow must be updated so that our central Identity Provider can handle routing European users to the EU org and North American users to the NA org based on a region attribute in the SAML assertion.
The lesson here applies directly to one of the 10 Commandments: never defend a position when the scenario explicitly contradicts it. The moment a judge points out a hard constraint, acknowledge it immediately, pivot, and trace the cascade. Stubbornly repeating ‘best practice’ when the facts say otherwise is one of the fastest ways to fail the board. This is a massive shift, but it is the only way to satisfy the compliance requirement.”
Follow-up: “With a multi-org strategy now in place, how do you plan to satisfy the CEO’s requirement for a consolidated global sales pipeline dashboard?”
Q1.5: Scripted Delivery and Conversational Architecture Fluency
Judge: “I asked you to explain your data model in your own words, and you just read directly from your slide deck word for word. Can you close your slides and actually tell me how these objects relate to each other and why you designed it this way?”
What they’re testing: Whether you truly understand your own architecture or are relying on memorized slides. Scripted delivery is a Tier 4 presentation failure. Judges want to see conversational fluency with the architecture, not recitation. This also tests composure when your safety blanket (slides) is removed.
Model answer: “You are right, and that is a fair challenge. I was leaning too heavily on my slides as a crutch. Let me close them and explain this conversationally.
At the heart of this data model, we have the Account object representing our client’s customers. Each Account can have multiple Opportunities tracking the sales pipeline, and each won Opportunity generates one or more Invoice records for billing.
The reason I designed the Invoice as a Lookup to Account rather than a Master-Detail is because regional managers need criteria-based sharing rules to see only invoices above $10,000 regardless of Account ownership. A Master-Detail would inherit the parent’s sharing, which blocks that requirement.
The Partner object sits alongside Account through a junction object because a single partner can service multiple accounts, and a single account can work with multiple partners. I chose a junction rather than a simple Lookup because the many-to-many relationship is a hard requirement from the partner onboarding team.
The key design tension in this ERD is between keeping the model simple for admin maintenance and making it flexible enough to handle the complex multi-partner, multi-region billing relationships. I optimized for the billing team’s reporting needs because that was the highest-priority requirement in the scenario.
I should be able to explain every relationship and the reasoning behind it without reading from a slide. Thank you for pushing me to demonstrate that.”
Follow-up: “Now that you have explained the data model conversationally, walk me through what happens at the database level when a sales rep reassigns an Account from one region to another.”
Type 2: Missed - “You Haven’t Addressed”
Q2.1: Missing Domain Coverage Due to Time Management Failure
Judge: “I noticed your presentation ended abruptly right after data migration. You never mentioned your deployment strategy, your environments, or your ongoing governance model. You’ve essentially missed an entire domain. How are you managing this implementation?”
What they’re testing: Whether you can recover from a massive time management failure where you failed to address all seven domains. Testing composure under pressure and ability to rapidly deliver a concise, structured summary of the missing domain on the spot.
Model answer: “You are completely correct, and I apologize for that omission. I mismanaged my time during the Data Model section and failed to execute my domain sweep, leaving Governance and Deployment completely unaddressed. I should have explicitly covered that in my presentation.
To address this critical gap immediately: I recommend establishing a Center of Excellence (CoE) featuring an Architecture Review Board and a Change Advisory Board to govern all ongoing changes. Because this is a complex, multi-region rollout, we cannot rely on informal processes.
For my environment strategy, I am recommending a multi-tier pipeline. Developers will use individual Developer Pro sandboxes, merging code into an integration branch that deploys to a Partial Copy sandbox for integration testing. From there, it moves to a Full Copy sandbox for User Acceptance Testing (UAT) and performance testing, before final deployment to Production.
For deployment tooling, I recommend using a CI/CD tool like Copado or AutoRABIT, combined with automated testing frameworks like PMD for static code analysis, to ensure metadata conflicts are caught early in the pipeline. My release cadence will be sprint-based, with major architectural releases scheduled quarterly. I appreciate you calling this out, as an unmanaged deployment would introduce severe risk to this enterprise architecture.”
Follow-up: “Since you mentioned a sprint-based release cadence, how do you handle hotfixes that need to go to Production immediately without disrupting the features currently sitting in your UAT environment?”
Q2.2: Missing Risk Acknowledgment and Happy Path Trap
Judge: “You’ve presented a very thorough technical solution, but I didn’t hear a single mention of project or architectural risks during your 45 minutes. Are there truly no risks in this multi-region ERP rollout, or did you just skip them?”
What they’re testing: Architectural maturity. Presenting only a ‘happy path’ without acknowledging limitations is a major presentation mistake. Judges expect proactive risk identification woven throughout the presentation, not bolted on at the end.
Model answer: “That is a very fair critique. I made the mistake of presenting only the ‘happy path’ and did not proactively articulate the risks inherent in my design. I should have addressed those explicitly throughout the presentation.
If I step back and apply a risk framework to the architecture I have proposed, the highest risk is the large data volume (LDV) migration from the legacy EMEA database. The probability of this risk is High due to the 50 million historical invoice records, and the impact is High because a failure will delay the global go-live.
To mitigate this risk, I am proposing a phased migration strategy using Bulk API 2.0 for the initial data load, with deferred sharing rule calculations and suspended validation rules during the load phase. I will request custom indexes on key fields before the load begins. As a contingency plan, if the data load exceeds our weekend cutover window, we will implement a parallel run strategy where the legacy system remains the source of truth for historical reporting for an additional 30 days while the load completes.
Going forward, I will ensure I highlight the trade-offs and risks alongside the technical solutions. That is one of the 10 Commandments: proactively acknowledge risks before a judge has to ask.”
Follow-up: “Regarding that data migration risk, how exactly are you validating the integrity of those 50 million records once they finally make it into Salesforce?”
Q2.3: Skipped Executive Summary and Technology-first Delivery
Judge: “You started your presentation by putting your System Landscape on the screen and immediately explaining your MuleSoft integrations. However, you didn’t provide any business context or assumptions. What business problem are we actually trying to solve here, and why are we building this?”
What they’re testing: Whether you can recognize and recover from a ‘technology-first design’ anti-pattern. The judges need to know that you understand the ‘why’ before the ‘how.’ Missing the executive summary that orients judges in the first 3 minutes is a critical failure.
Model answer: “You are absolutely right, and I apologize for jumping straight into the technology. I skipped the executive summary and committed a solution dump without framing the business problem. Let me step back and set the stage correctly.
The core business challenge described in the scenario is that the client needs to unify three distinct business units with completely isolated sales processes, while strictly maintaining regulatory data compliance in the European region. The three critical requirements driving my entire architecture are: establishing a unified 360-degree customer view, reducing partner onboarding time from weeks to days, and ensuring European data residency laws are not violated.
My key assumptions are: first, the legacy ERPs cannot be retired for at least three years, making coexistence mandatory. Second, standardizing the sales process takes priority over preserving legacy custom fields. Third, the European data residency constraint is non-negotiable and drives the entire security and org strategy.
My approach prioritizes a consolidated org strategy with highly selective, middleware-driven integrations. The reason I focused on MuleSoft is because the integration layer is the absolute critical path to achieving that 360-degree customer view across three ERPs. By anchoring my MuleSoft design to the goal of unifying those business units, the technical choices serve the business need.
The lesson I will apply going forward: always open with a 3-minute executive summary covering the business problem, my top 3 assumptions, and the architectural approach before touching any diagram. That framing gives the judges the context to evaluate every subsequent technical decision.”
Follow-up: “Given that business goal of unifying the three business units, what were the trade-offs you accepted by choosing a single-org strategy instead of keeping them in separate orgs?”
Q2.4: Deferred Question Recovery and Q&a Time Management
Judge: “Earlier in the Q&A, I asked you how external partner users would be provisioned into the community. You said you needed to review your notes and would come back to it, but our time is almost up and you haven’t mentioned it. How are those users provisioned?”
What they’re testing: Q&A management discipline. Whether you can recover from forgetting a deferred commitment under time pressure. Testing poise: will you panic when caught, or seamlessly supply the missing architectural element on the spot?
Model answer: “You are entirely correct, and I apologize. I deferred that question earlier and completely lost track of it during our deep dive into the integration layer. Thank you for bringing it back up; I absolutely should have addressed that explicitly before we ran out of time.
To answer your question directly: for the external partner users, my strategy is to use Just-In-Time (JIT) provisioning via our SAML Identity Provider.
I chose this approach rather than a nightly batch integration or manual creation because the scenario states that partners need immediate access to the portal the moment their contract is signed in the external billing system. When a partner clicks the login link from their welcome email, the Identity Provider will authenticate them and send a SAML assertion to Salesforce. I will use a custom JIT Apex handler to intercept that assertion, read the partner attributes, and automatically provision the User record, assign the Partner Community license, and attach them to the correct Account on the fly. This ensures real-time access without the overhead of maintaining point-to-point user sync integrations.
In the future, when I defer a question, I will note it visibly on my whiteboard so I do not lose track.”
Follow-up: “If you are using a custom JIT Apex handler to create these users, how are you ensuring that they are assigned to the correct level in the Partner Role Hierarchy so they don’t accidentally see other partners’ data?”
Q2.5: Missing Change Management and User Adoption Planning
Judge: “You walked through security, data model, and integrations in great detail, but I noticed you never mentioned change management or user adoption. You have 500 sales reps transitioning from a system they have used for eight years. How are you handling the human side of this rollout?”
What they’re testing: Whether you treat architecture as purely technical or understand the consulting dimension. Change management and user adoption are D4+D7 concerns that judges increasingly probe. A technically sound architecture that ignores 500 users transitioning fails the board.
Model answer: “That is a critical gap in my presentation, and I appreciate you calling it out. I focused entirely on the technical architecture and neglected the human side of this transformation, which is just as important to project success.
My change management strategy has three pillars. First, stakeholder champions: I would identify 10-15 power users across regions to serve as early adopters and internal trainers. They participate in UAT, provide feedback on the UI design, and become the first line of support during go-live. This reduces the perception that the new system is being imposed from IT.
Second, phased training: Rather than a single training dump before go-live, I would run four two-week training sprints aligned with our deployment phases. Each sprint focuses on one functional area, for example Sales Process first, then Reporting, then Partner Portal. This prevents information overload and lets users build confidence incrementally.
Third, adoption metrics: I would build a Salesforce dashboard tracking login frequency, record creation rates, and feature usage per team. If the European team’s adoption drops below 60% in week two, that triggers an escalation to the regional VP and a targeted intervention.
The trade-off of investing in change management is that it adds 3-4 weeks to the timeline and requires dedicated business analyst resources. But the alternative, a technically perfect system that nobody uses, is a much more expensive failure.”
Follow-up: “The European sales team says they will keep using the legacy system in parallel ‘just in case.’ How do you handle the dual-system problem without forcing a hard cutover?”
Type 3: Suboptimal - “Have You Considered”
Q3.1: Happy-path-only Diagram Missing Error Flows
Judge: “I am looking at your Integration Architecture diagram for the legacy ERP synchronization. It clearly outlines the system nodes, the data flow direction, and the REST protocol, but it seems to only represent the happy path. Have you considered what happens visually and architecturally if this integration fails at 2 AM?”
What they’re testing: Whether you recognize that an enterprise-grade integration diagram must show the error path, not just the happy path. Error flows are probed in 80%+ of board sessions. Testing whether you can accept the critique and immediately supply the missing failure scenarios.
Model answer: “You make an excellent point. I created a diagram that successfully captures the happy path but omitted the critical error handling flows, which makes this artifact suboptimal for an enterprise design. I should have explicitly documented the failure scenarios on the visual artifact.
If we look at that specific REST integration from the ERP to Salesforce, I would update the diagram to include an explicit error path. If the integration fails at 2 AM due to a Salesforce system timeout or lock, my middleware layer (MuleSoft) will intercept the HTTP 500 error. The error path on my diagram would show MuleSoft attempting a standard retry policy: three retries with exponential backoff.
If the retries are exhausted, the diagram would show the payload being routed to a Dead Letter Queue (DLQ) within MuleSoft. I would also visually indicate an alerting mechanism where MuleSoft sends an immediate notification to the IT support channel via PagerDuty or a dedicated Slack channel.
Visually, I would use a red dashed line to represent the error path, clearly distinct from the green solid line of the happy path. The DLQ node would be annotated with the retention period and the reprocessing trigger. This notation follows the one-diagram-one-message principle while still showing both paths without cluttering the artifact.
By introducing these visual elements, the artifact moves from a simple data flow to a true enterprise architecture diagram that accounts for inevitable system failures. I appreciate you pointing out that missing visual component.”
Follow-up: “Now that you have introduced a Dead Letter Queue to handle the failure, what is the exact business and technical process for reprocessing those records once the underlying issue is resolved?”
Q3.2: Object-by-object Narrative vs Business Story
Judge: “During your solution walk-through, you detailed the creation of five custom objects, two flows, and a custom trigger, but I am struggling to see the bigger picture. Have you considered framing this around the sales team’s actual user journey instead of giving us an object-by-object list?”
What they’re testing: Whether you can recognize the ‘solution dump’ anti-pattern where you deliver a disjointed metadata checklist instead of a business-first narrative. Testing your ability to pivot from technical enumeration to a user-journey-driven story that ties every component to business value.
Model answer: “That is a very fair critique. I fell into the trap of delivering a technology-first solution dump rather than anchoring my presentation in the business narrative. Explaining metadata in isolation is suboptimal because it completely obscures the business value we are trying to achieve. Let me step back and reframe this.
The core business requirement here is that the sales team needs to drastically reduce the time it takes to onboard a new retail partner, which currently takes three weeks. The user journey starts when the Sales Rep clicks ‘Initiate Onboarding.’
Instead of listing objects, I will explain the flow: I built the custom Lightning Web Component to act as a unified intake form so the rep does not have to navigate across five different related lists. When they click submit, the Flow I mentioned automatically handles the complex approval routing across the legal and finance departments. I only introduced that custom trigger because the volume of concurrent onboarding requests risks exceeding declarative limits.
Every piece of custom metadata I built is specifically designed to eliminate friction in that rep’s journey, reducing the onboarding process from weeks to hours. Going forward, I will ensure I lead with the business ‘why’ before the technical ‘how.’”
Follow-up: “Framing it around the user journey clarifies a lot. From that business perspective, which of these new custom features introduces the highest adoption risk for the sales team?”
Q3.3: Defending Declarative Approach Beyond Its Limits
Judge: “You seem very committed to using standard declarative Flows for the territory realignment process. While I understand you want to avoid custom code, have you considered the limitations of Flows for this specific data volume and complex hierarchy?”
What they’re testing: Whether you will rigidly defend a ‘best practice’ (Clicks over Code) to the point of breaking the system, or if you can step back, acknowledge the severe trade-offs, and adapt to a better architectural fit when the scenario demands it.
Model answer: “You are right to challenge that, and I was focusing entirely on the benefits of avoiding custom code without adequately acknowledging the very real limitations of Salesforce Flow in this specific context. I chose Flow initially because it is natively maintainable by admins and aligns with general platform best practices.
However, evaluating it against the scenario’s requirement to realign 2.5 million Account records and execute complex, multi-level hierarchy calculations, relying solely on Flow is a suboptimal and potentially failing approach. The primary trade-off I failed to highlight is that declarative automation is governed by strict CPU time limits and element execution limits. A Flow processing that volume of complex data relationships will almost certainly hit a LimitExceeded exception and fail.
Therefore, I need to adapt my approach. Because the requirement involves millions of records and complex hierarchy logic, I will pivot from a declarative Flow to a programmatic Batch Apex process. Batch Apex allows us to chunk the processing into manageable discrete batches, cleanly avoiding synchronous governor limits while securely recalculating the territory structure. Thank you for calling out that limitation.
Using the trade-off formula: I gave up admin maintainability, the condition that would change my mind is if the volume drops below 50,000 records, and the alternative I rejected was Queueable chaining, which adds unnecessary complexity.”
Follow-up: “Now that you have pivoted to Batch Apex, what happens if the business users need to trigger this territory realignment in the middle of the workday?”
Q3.4: Over-explaining and Monologue Answers in Q&a
Judge: “I just asked you why you chose the JWT Bearer OAuth flow, and you spent four minutes explaining the history of SAML, Identity Providers, and various token types before finally answering. Have you considered a more direct approach to explaining your architecture choices?”
What they’re testing: Q&A management and the ability to be Correct and Concise (CC). Penalizing a ‘monologue answer’ that loses the judges’ attention and wastes finite exam time. Testing whether you can accept the feedback gracefully, drop the preamble, and use the STAR-A framework.
Model answer: “I completely agree with your feedback, and I apologize for the monologue. I failed to be correct and concise, and I recognize that providing that much generalized preamble dilutes the core architectural message and wastes our finite time.
To answer your question directly using the STAR-A framework: the Situation is a server-to-server integration between the external billing system and Salesforce with no human user in the loop. My Thinking was that because no human user is present to enter credentials or click an authorization screen, we need a flow that authenticates entirely through machine credentials. My Answer is the JWT Bearer OAuth flow. The Rationale is that it relies on prior approval and exchanging a digitally signed certificate for an access token, which perfectly solves the requirement for an automated, secure, background system integration without storing user passwords.
To Adapt: if the requirement changes to include a human-initiated flow from a partner portal, I would switch to the Web Server OAuth flow instead. If the external system cannot manage X.509 certificates, I would fall back to Client Credentials flow, though that trades certificate-based security for shared secret management.
The alternatives I rejected: the Username-Password flow, because it is insecure and blocked by default in orgs created Summer ‘23 onward. Client Credentials flow is a better fallback if certificate management is not feasible. The Device flow, because there is no device involved in a server-to-server context. Each rejection maps to a specific technical limitation, not just preference.
I will keep my answers focused directly on the specific ‘what’ and ‘why’ moving forward. The STAR-A framework keeps me under 90 seconds per answer, which is the target for board Q&A responses.”
Follow-up: “Since this flow uses digital certificates for trust, how will you govern the certificate lifecycle to ensure the integration doesn’t suddenly fail when the certificate expires?”
Q3.5: Audience Tailoring Between Technical and Business Language
Judge: “You just explained your data archival strategy using terms like ‘PK Chunking’, ‘hard deletes’, and ‘database indexing’. If I were the VP of Sales listening to this presentation, I wouldn’t understand a word. Have you considered how to explain this architecture to a business stakeholder?”
What they’re testing: Whether you can act as a bridge between IT and the C-suite. Testing your ability to instantly strip away technical jargon and translate architecture into a value-driven statement that resonates with an executive audience.
Model answer: “That is a very valid critique. I defaulted to highly technical terminology, which is appropriate for a developer audience but completely suboptimal for a business stakeholder.
If I were explaining this archival strategy to the VP of Sales, I would strip away the system jargon and focus entirely on system performance, user experience, and cost value. I would frame the conversation like this:
‘To ensure your sales team can search for their critical accounts instantly and without frustrating load screens, we need to keep the Salesforce database lean. We are proposing a strategy to take all the closed invoices that are over three years old, data your team rarely needs day-to-day, and move them into a highly secure but much cheaper secondary storage system. Your team will still be able to access those old records if they need them for an audit, but getting them out of the primary system ensures that Salesforce remains lightning-fast for their daily selling activities.’
By framing the architecture around the sales team’s speed and operational cost, the VP of Sales understands the value without needing to understand the mechanics. The 10 Commandments emphasize this: always adapt your language to the audience in front of you.”
Follow-up: “If the VP of Sales pushes back on that non-technical explanation and insists that all historical invoices must remain natively in Salesforce forever, how do you handle that objection?”
Q3.6: Time Management Recovery and Domain Coverage Triage
Judge: “You have been presenting for 38 minutes and you still haven’t covered governance, deployment, or your phased roadmap. You have 7 minutes left. Have you considered that your time management might be a bigger problem than the architecture itself?”
What they’re testing: Whether you can recover from a severe time management failure in real time. Time management collapse (spending 15+ minutes on one domain, running out before covering all seven) is a Tier 1 critical failure. Testing whether you can instantly triage, summarize the missing domains in 2-3 sentences each, and still close with a risk summary.
Model answer: “You are absolutely right, and I need to address this immediately rather than continuing to add detail to areas I have already covered. I made a time management error by spending too long on the integration deep dive, and I need to course-correct right now.
With 7 minutes remaining, here is my plan. I will spend 90 seconds each on Governance, Deployment, and Roadmap, then close with 60 seconds on risks and next steps.
Governance: I recommend a Center of Excellence with an Architecture Review Board meeting biweekly to approve all changes to the core data model and integration layer. A Change Advisory Board reviews production deployments.
Deployment: A four-tier environment pipeline: Developer Pro sandboxes, Partial Copy for integration testing, Full Copy for UAT, and Production. CI/CD through Copado with automated PMD scanning and mandatory code review gates.
Phased Roadmap: Phase 1 in months 1-4 delivers Sales Cloud core and the primary ERP integration. Phase 2 in months 5-8 adds the Partner Portal and Community. Phase 3 in months 9-12 delivers Marketing Cloud and advanced analytics.
Top risks: LDV migration timing, middleware team readiness, and European user adoption. Each has a documented mitigation and contingency.
In hindsight, I should have set internal checkpoints at the 15, 30, and 40 minute marks to ensure domain coverage. That is a lesson I will apply in my next rehearsal.”
Follow-up: “You just covered three domains in 4 minutes. How do you ensure the judges feel those domains were adequately addressed given the compressed delivery?”
Type 4: Rationale Missing - “WHY”
Q4.1: Presentation Order Rationale and Dependency Mapping
Judge: “During your presentation, I noticed you chose to present your Role Hierarchy and Sharing model before your System Landscape. Most candidates start with the Landscape to set the scene. Why did you choose this specific presentation order?”
What they’re testing: Whether you are blindly following a template or genuinely understand the dependency map of your own architecture. Testing if you can articulate the rationale behind structuring the 45-minute presentation based on scenario-specific priorities.
Model answer: “I chose to present the Role Hierarchy first because the sharing model is foundational to this specific scenario and directly constrains every subsequent design decision.
I considered starting with the System Landscape, which is the traditional approach to set high-level context. However, I rejected it for this scenario because the strict European data residency and complex multi-tenant partner portal requirements mean the security model dictates what integrations and data flows are even permissible. If I had presented the System Landscape first showing all data flowing freely between regions, a judge would immediately challenge the compliance violation, and I would be defending a flawed diagram from the start.
The trade-off of this approach is that we dive into detailed security concepts, like external sharing rules and org-wide defaults, before visualizing the overall system ecosystem. I mitigated this by providing a strong 3-minute executive summary to verbally frame the ecosystem beforehand. By establishing the OWD and role branches first, we could evaluate the subsequent System Landscape and Data Model through the correct, highly restrictive security lens. It ensures the narrative flows from the most critical constraint downward.
This is the dependency-driven presentation order principle: identify the single design decision that constrains the most downstream choices, and present that first. The condition that would change my mind: if the scenario had straightforward security but complex multi-cloud integrations, I would lead with the System Landscape instead.”
Follow-up: “Given that security drove your narrative, how does your Role Hierarchy directly inform your decision to use a single org instead of a multi-org strategy?”
Q4.2: Diagram Style Rationale and Audience Readability Trade-offs
Judge: “Your Data Model and System Landscape diagrams use a very specific card-based visual style with color-coded boundaries, rather than standard UML or C4 notation. Why did you choose this visualization framework for a highly technical enterprise architecture?”
What they’re testing: Whether you can articulate the rationale behind your visual design choices, specifically balancing the trade-off between strict technical notation (UML) and executive readability (the Salesforce Diagramming Framework).
Model answer: “I chose to use the official Salesforce Diagramming Framework, which relies on a card-based structure, rather than standard UML. I made this choice because the scenario requires me to communicate the architecture to a mixed audience of both technical implementation teams and business stakeholders, such as the VP of Sales.
I considered using formal UML or C4 models, which offer more rigorous semantic structures. However, I rejected them because they often introduce too much visual density and specialized jargon for executive stakeholders to quickly parse on a shared screen. During the 180-minute prep, building production-quality UML sequence diagrams also takes significantly longer than card-based layouts, which would eat into time I needed for solution design.
The trade-off is that we sacrifice some of the strict notations of UML, such as detailed method signatures or object state transitions. I mitigate this by layering my artifacts: I use the readable, color-coded System Landscape for the main presentation, and I maintain detailed Google Sheets reference tables for the exact integration protocols, frequencies, and payloads to address deep technical questions during Q&A. This ensures the visual artifacts pass the 10-second readability test while preserving technical depth in the backup material.
The layered artifact approach is the key mitigation: presentation-level diagrams optimized for readability, backed by reference-level tables optimized for precision. If the CIO specifically asks for a sequence diagram, I can draw that on demand during Q&A using the data already captured in my reference tables.”
Follow-up: “If the CIO specifically asks for a Level 4 sequence diagram of your SSO authentication flow, how would you adapt this card-based style to satisfy that deep technical requirement?”
Q4.3: Artifact Prioritization Under Time Pressure
Judge: “I see you provided very detailed System Landscape, Data Model, and Role Hierarchy diagrams, but you didn’t include a dedicated visual diagram for the Data Migration strategy, choosing to speak to it verbally instead. Why did you prioritize your diagramming time this way?”
What they’re testing: Time management and decision-making under pressure. Whether your artifact prioritization correctly matched the risk profile of the scenario and whether you can justify applying the 80/20 rule during the strict 180-minute prep phase.
Model answer: “I chose to invest 80% of my diagramming time into the Big 3 diagrams (System Landscape, Data Model, and Role Hierarchy) and prioritized them over a dedicated Data Migration diagram. I made this choice because the scenario presented heavily complex, multi-system integration requirements, but the migration data volume was relatively simple at only 500,000 core records without complex legacy transformations.
I considered building a full sequence diagram for the ETL migration flow. However, I rejected it because doing so within the 180-minute prep window would have required sacrificing critical detail on the System Landscape’s middleware layer, which carried a much higher architectural risk for this specific client. The 180-minute prep demands ruthless prioritization: every hour spent on a lower-risk artifact is an hour stolen from a higher-risk one.
The trade-off is that you do not have a visual artifact to anchor the migration discussion. To mitigate this, I used my tabular notes to verbally communicate the exact migration sequence, ETL tooling, and validation steps clearly during the domain sweep. Verbal delivery can be just as effective as a diagram if structured with clear phases: extract, transform, load, validate, and cutover.
The decision framework I applied: rank each potential diagram by the scenario’s risk profile, allocate Big 3 diagrams first, then ask whether any remaining domain carries enough risk to justify a fourth diagram. For this scenario, migration did not cross that threshold. If the scenario had specified 50 million records with complex parent-child relationships, I would have built the migration diagram and simplified my integration diagram instead.”
Follow-up: “If the scenario had instead specified migrating 50 million historical invoices with complex parent-child relationships, how would you have altered your 180-minute time allocation?”
Q4.4: Risk Selection Rationale and Probability-impact Filtering
Judge: “On your final slide, you highlighted three project risks: Large Data Volume performance, middleware team readiness, and user adoption. There are dozens of potential risks in a global enterprise rollout. Why did you select these specific three risks to present?”
What they’re testing: Risk communication framework and architectural maturity. Whether you can articulate the rationale for filtering noise and identifying the risks with the highest combined probability and impact specifically tied to the business context.
Model answer: “I chose to highlight those three specific risks because they represent the highest combined probability and impact for this specific business scenario.
I considered including standard technical risks, such as governor limit breaches, complex deployment overwrites, or SSO certificate expiration. However, I rejected them for the executive summary because those are standard operational risks that my architecture inherently mitigates through batch processing and our CI/CD pipeline. Presenting mitigated risks wastes presentation time and signals to judges that you cannot distinguish between resolved and unresolved threats.
The trade-off of limiting my presentation to just three risks is that it might appear I have not considered the broader operational challenges of the platform. I mitigated this by keeping a detailed risk register in my notes to address during Q&A. If a judge asks about a fourth or fifth risk, I can pull it from the register immediately.
I prioritized LDV performance because the 10 million historical orders directly threaten the strict sub-two-second page load SLA. I highlighted middleware readiness because my entire single-org integration strategy depends on a MuleSoft team that the client has not yet hired, making it the highest-probability risk. Finally, I included user adoption because the scenario explicitly noted severe resistance from the European sales team, and no architecture succeeds if users refuse to use it.
The framework I applied: probability times impact, filtered by business-criticality, not technical-criticality. Each risk also has a documented mitigation and a contingency plan if the mitigation fails.”
Follow-up: “Regarding the user adoption risk you prioritized, what specific contingency plan do you have in place if the European sales team outright refuses to log into the new system during week one?”
Q4.5: Judge Panel Dynamics and Adaptive Communication
Judge: “I notice you are addressing every question from every judge with the same level of technical depth. Judge Chen asked a high-level business question and you gave a five-minute technical deep dive. Judge Patel asked a technical question and you gave a brief business summary. Why are you not adapting your responses to the specific judge asking the question?”
What they’re testing: Whether you can read the room and adapt communication style to different judge personas. Real boards have 3-5 judges with different backgrounds (technical architect, business consultant, program manager). Failing to tailor depth and language to each judge is a significant D7 scoring failure.
Model answer: “That is an important observation, and you are right that I have been treating every judge question with the same response style. I should be reading the room and adapting.
Using the Acknowledge-Reason-Alternatives framework: I acknowledge that Judge Chen’s question about business alignment needed a concise, value-driven answer focused on ROI and user impact, not a walkthrough of the API architecture. And Judge Patel’s question about the integration retry logic needed specific technical depth with protocol names, timeout values, and error codes, not a business summary.
The framework I should be applying is: identify the judge’s role and intent from how they phrase the question. Business-oriented questions use words like ‘value,’ ‘cost,’ ‘impact,’ and ‘users.’ Technical questions reference specific technologies, patterns, limits, and configurations. My response style should match.
For business-oriented judges, I will lead with the business outcome, state the trade-off in cost or timeline terms, and offer to go deeper if they want. For technical judges, I will lead with the specific architecture decision, name the exact technology and configuration, and trace the technical impact chain.
Going forward, I will also watch for non-verbal cues. If a judge is leaning in and nodding, they want more depth. If they are looking at their notes or glancing at the clock, I need to wrap up and move to the conclusion. Thank you for that feedback.”
Follow-up: “Judge Chen just asked you a follow-up question that sits right at the boundary between business and technical. How do you decide which framing to use when the question is ambiguous?”
Type 5: Cascading - “If You Change X”
Q5.1: Owd Change Cascading to Portal Access, Integration, and Reporting
Judge: “You initially set the Order object to a Public Read Only Org-Wide Default, but let’s say the Chief Information Security Officer just mandated that all financial objects must be strictly Private. If you change that OWD to Private right now, walk me through what happens to your integration flows, the partner portal access, and your reporting strategy?”
What they’re testing: Whether you can trace cross-domain dependencies in real time. Specifically testing the rule that ‘OWD is the foundation of the sharing pyramid.’ Expecting you to pause, mentally trace the impact chain across Security (D2), Integration (D5), and Reporting, and verbally articulate the fixes required in each domain without losing track.
Model answer: “That is a critical security constraint. Changing the Order OWD to Private triggers a massive cross-domain cascade across my architecture. I will adjust the OWD to Private and trace the impacts across those three areas.
First, looking at Security and Portal Access (D2): Previously, the 50,000 external users could see all orders. With a Private OWD, they immediately lose access to everything they do not own. Before I talk about the fix, I need to be precise about the license family, because the options differ. Partner Community (now Partner User) and Customer Community Plus are distinct Experience Cloud license families — Partner licenses are meant for indirect sales channels managing leads, opportunities, and deals with access to Account, Contact, Lead, Opportunity, Case and custom objects, while Customer Community Plus is meant for customers or B2B buyers and excludes the sales objects. Both license families support roles and sharing rules, so the sharing recovery pattern is similar: criteria-based or ownership-based sharing rules scoped to each external user’s Account, restoring visibility to only their own company’s orders. If this scenario were instead on basic Customer Community licenses (which do not support roles or sharing rules), I’d be forced onto Sharing Sets keyed to the Account lookup on the portal Contact. For this scenario I’ll assume a homogeneous license family (either Partner User or Customer Community Plus, but not mixed) and size the sharing approach accordingly.
Second, examining my Integration Architecture (D5): My MuleSoft integration is pushing ERP updates to the Order object using a dedicated Integration User. If the OWD is Private, that integration will fail with access errors when updating records owned by sales reps. To fix this, I must update my security model to grant the Integration User profile ‘Modify All’ permission on the Order object, ensuring the API integration can still execute successfully.
Finally, regarding Reporting: The VP of Sales required a global pipeline dashboard showing all orders. With a Private OWD, the VP will only see orders rolling up through their specific branch of the Role Hierarchy. To mitigate this, I will implement a Criteria-Based Sharing Rule granting Read access to the ‘Global VP’ Public Group, or I will adapt my reporting strategy to use a CRM Analytics dashboard running as a designated user, bypassing the restrictive transactional security for analytical purposes.”
Follow-up: “Given that you are now relying on Sharing Sets for the 50,000 portal users, what happens to your design if the business demands that partners must also manually share specific orders with external third-party contractors?”
Q5.2: Timeline Compression Cascading to Scope, Deployment, and Artifacts
Judge: “The CEO just announced that due to severe budget constraints, the 12-month big-bang rollout we discussed is being cut to 6 months. If you compress this implementation timeline by half, how does this change your deployment strategy, what scope are you cutting, and how would you verbally revise your presentation artifacts to reflect this?”
What they’re testing: Handling unexpected roadblocks. Forcing a cascade that originates in project management but heavily impacts Development Lifecycle (D6) and Solution Architecture (D4). Testing whether you can rapidly triage requirements, sacrifice ‘nice-to-have’ features, and adapt your visual presentation narrative to reflect a phased approach.
Model answer: “That timeline constraint changes the entire complexion of the project. I cannot deliver a 12-month scope in 6 months without introducing severe project risk. Therefore, I must immediately pivot my architecture from a big-bang release to a phased Agile delivery model, which cascades across my scope, deployment, and visual artifacts.
Starting with Scope and Solution Architecture (D4): To meet the 6-month deadline, I must ruthlessly cut custom development. I will drop the custom Lightning Web Component I designed for the complex onboarding wizard and revert to a standard Screen Flow. The trade-off is a slightly less branded, click-heavy user interface, but the mitigation is that it guarantees we hit the 6-month go-live date.
Next, looking at Deployment Strategy (D6): My CI/CD pipeline and environment strategy must accelerate. I will defer the implementation of full automated regression testing (Selenium) to Phase 2. For Phase 1, we will rely on standard Apex unit tests and manual User Acceptance Testing in the Full Copy sandbox. We will also adopt a strict 2-week sprint cadence with a minimal viable product scope lock.
Finally, regarding my Communication Artifacts (D7): If I were to redraw my System Landscape and Data Model right now, I would use the mandatory legend conventions to clearly separate Phase 1 from Phase 2. I would draw dashed lines around the Marketing Cloud integration and the custom Survey objects to denote them as ‘Future State,’ while keeping Sales Cloud and the core ERP integration in solid lines as ‘Current State.’ This visually communicates to the CEO exactly what they are getting in 6 months and what is deferred.”
Follow-up: “By deferring automated regression testing to Phase 2 to save time, how are you mitigating the massive quality risk introduced during your bi-weekly MVP sprints?”
Q5.3: Middleware Removal Cascading to Landscape, Error Handling, and Migration
Judge: “You’ve built your entire integration architecture and System Landscape assuming MuleSoft is available. I’m telling you right now, MuleSoft licensing was definitively rejected by the procurement board this morning. If you drop MuleSoft entirely, what happens to your System Landscape, your error handling strategy, and your data migration plan?”
What they’re testing: Handling roadblocks and the fundamental rule that enterprise architectures almost always require an integration layer. Stripping away core middleware to force a massive cascade. Testing whether you will panic or smoothly transition to a fallback while tracing impacts on error handling and ETL.
Model answer: “That is a massive architectural shift. If MuleSoft is entirely off the table, I must immediately adapt my architecture because removing the middleware layer cascades into integration reliability, visualization, and migration planning.
First, impacting my System Landscape (D1/D7): I cannot simply draw direct point-to-point arrows from Salesforce to the legacy ERP; doing so would violate enterprise architecture standards. Instead, I will revise my diagram to replace MuleSoft with a more cost-effective API Gateway, such as AWS API Gateway, combined with an ETL tool like Talend or Jitterbit that the client may already own.
Second, this heavily impacts my Integration Architecture and Error Handling (D5): Without MuleSoft’s native Dead Letter Queues and automatic retry mechanisms, I must push that orchestration logic elsewhere. I will revise my integrations to rely more heavily on Salesforce’s native asynchronous features. For outbound messages to the ERP, I will use Platform Events for event-driven communication. Platform Events provide 72-hour retention where subscribers manage replay position, but they are not a dead letter queue or automatic retry mechanism. I will build a custom Apex retry framework within Salesforce to catch callout failures, log them to a custom Integration_Error__c object, and use a Scheduled Batch Apex job to retry the failed payloads.
Finally, looking at Data Migration (D3): I originally planned to use MuleSoft to transform and load the 2 million historical records. Without it, I will adapt my strategy to use a dedicated ETL tool, like the Salesforce Data Loader CLI or Talend, extracting flat files from the legacy database, cleansing them in a staging database, and using the Bulk API 2.0 to push them into Salesforce. This ensures the migration remains performant despite the loss of our primary middleware.”
Follow-up: “Now that you are building a custom Apex retry framework inside Salesforce, what specific governor limits are you most concerned about hitting when the ERP goes down for 24 hours?”
Q5.4: Business Driver Shift Cascading to Org Strategy, Identity, and Lifecycle
Judge: “Your entire executive summary and architecture assumed that standardizing the global sales process was the top priority. Actually, the scenario heavily implied that protecting European data residency and keeping EU data physically out of the US was the absolute highest priority. If you shift your primary business driver to data residency, how does that cascade through your Org Strategy, your Identity flow, and your visual diagrams?”
What they’re testing: Whether you will stubbornly defend a Single Org or gracefully pivot to a Multi-Org strategy and trace how that fractures the rest of your system. By shifting the core business driver, the judge forces a meta-cascade that rips up your foundational Org Strategy.
Model answer: “You make an excellent point, and I misaligned my primary business driver. If European data residency and physical database separation is the absolute highest priority, my current Single Org strategy is fundamentally invalid because it commingles EU and US data in the same geographic instance. I must pivot immediately to a Multi-Org strategy, which triggers a massive architectural cascade.
First, looking at Org Strategy and System Landscape (D1/D7): I will revise my architecture to provision two separate Salesforce instances, one hosted in the EU infrastructure and one in the US. Visually, my System Landscape diagram must be redrawn to show two distinct ‘Salesforce Cloud’ boundaries. The middleware layer now sits between the two orgs to handle strictly regulated, aggregated data sharing where legally permissible.
Second, this breaks my Identity and SSO flow (D2): Previously, my Identity Provider (Okta) routed everyone to one org. Now, I must adapt the IdP configuration to evaluate the user’s region attribute upon authentication and dynamically route EU users to the EU org’s Service Provider endpoint, and US users to the US org.
Finally, this severely impacts Development Lifecycle (D6): We now have to manage metadata across two distinct orgs. To prevent the orgs from diverging and creating technical debt, I will implement a unified CI/CD pipeline using a tool like Copado, mandating that all global custom metadata and Apex is deployed from a single source-control repository to both orgs simultaneously. The Multi-Org approach is the only way to satisfy that strict legal constraint.”
Follow-up: “With EU and US data now sitting in completely separate physical orgs, how will you satisfy the CEO’s requirement for a real-time, consolidated global sales forecasting dashboard?”
Q5.5: Stakeholder Demand Cascading to Lifecycle, Budget, and Mobile
Judge: “Let’s say the VP of Sales reviews your architecture and absolutely refuses your declarative Screen Flow solution because it takes ‘too many clicks.’ They demand a fully customized, highly dynamic Lightning Web Component intake form. If you accept their demand and change the UI to a custom LWC, what happens to your development lifecycle, your project budget, and your mobile architecture?”
What they’re testing: Whether you can handle stakeholder objections and act as a consulting architect. Forcing a cascade from Solution Architecture (D4, Clicks vs. Code) into Development Lifecycle (D6) and System Architecture (D1). Testing whether you can articulate the severe hidden costs of custom code to a business stakeholder.
Model answer: “If the VP of Sales mandates a fully custom Lightning Web Component, I will adapt the solution to meet their user experience demands, but I must immediately advise them that moving from declarative ‘clicks’ to custom ‘code’ triggers a significant cascade across our timelines, budget, and testing cycles.
First, regarding the Development Lifecycle (D6): Custom code requires a much higher level of engineering rigor than a Screen Flow. This changes our CI/CD pipeline requirements. I must introduce strict static code analysis using tools like PMD or ESLint to ensure the JavaScript and Apex controllers meet security standards. On top of that, our testing cycle elongates because we must write and maintain Jest tests for the LWC UI and Apex unit tests for the backend, whereas Flow logic is largely natively tested.
Second, impacting Budget and Resourcing (D1/D6): We can no longer rely on Salesforce Administrators to maintain or update the intake form. I will need to staff senior Salesforce Developers on the project, which significantly increases the baseline implementation cost and introduces a long-term maintenance dependency on technical resources.
Finally, impacting the Mobile Architecture (D1): Standard Screen Flows are natively mobile-responsive out of the box. An LWC is not automatically responsive unless explicitly designed to be. I must expand the development scope to include specific CSS frameworks, like the SLDS grid, to ensure the custom component renders correctly on the reps’ iPads and mobile devices. The VP gets their streamlined UI, but the trade-off is a heavier, more expensive, code-reliant architecture.”
Follow-up: “Given that you now have a highly customized LWC interacting directly with the database, how do you handle Field Level Security (FLS) to ensure the component doesn’t expose fields the user shouldn’t see?”
Q5.6: Data Volume Revelation Cascading to Erd, Reporting, and Migration
Judge: “You designed your Data Model assuming the ‘Invoices’ object has 2 million records. I’m telling you there was a typo in the requirements; it’s actually 50 million records. If you change that volume to 50 million, what happens to your ERD relationships, your reporting strategy, and your data migration sequence?”
What they’re testing: Large Data Volume mismanagement and the cascading impact of data volumes. Testing the rule that ‘Objects ripple through every layer.’ Expecting you to recognize that 50M records immediately breaks native reporting, forces changes to Master-Detail relationships, and completely alters the ETL plan.
Model answer: “A jump from 2 million to 50 million records fundamentally changes this from a standard data scenario to a severe Large Data Volume architecture. That revelation triggers a massive cascade across my Data Model, Reporting, and Migration strategies.
First, revising my Data Model (D3 / ERD): At 50 million records, a Master-Detail relationship between Account and Invoice creates a severe risk of data skew, sharing table growth, and recalculation overhead. The sharing tables expand with every role-based and rule-based access grant, which directly impacts recalculation time and query performance at this scale. I must instantly revise my ERD to change the Invoice relationship from a Master-Detail to a standard Lookup.
Second, this breaks my Reporting Strategy: Native Salesforce reports scanning a 50 million record table will almost certainly hit query timeout limits and fail. I must pivot my reporting architecture. Instead of native dashboards, I will use CRM Analytics (formerly Tableau CRM) or push the data to an external Data Warehouse (like Snowflake) to handle the aggregations and intense analytical workloads off-platform.
Finally, this completely rewrites my Data Migration Sequence (D3): Loading 50 million records via standard APIs would take weeks. I must adapt my ETL plan to use the Bulk API 2.0. Before the load begins, I will defer all Sharing Rule calculations and disable all Apex triggers, workflows, and validation rules on the Invoice object. I will also log a proactive ticket with Salesforce Support to enable custom database indexing, and tune the Bulk API 2.0 batch sizes while disabling automation during load to ensure the migration completes within our weekend cutover window. That volume changes everything.”
Follow-up: “Since you changed the Master-Detail to a Lookup to avoid locking, how will you fulfill the requirement to show the ‘Total Invoice Value’ roll-up summary on the Account page?”
Q5.7: Live Architecture Adaptation and Artifact Consistency During Q&a
Judge: “During Q&A, I challenged your sharing model and you acknowledged it was wrong and proposed a fix. But you just moved on to the next question without updating your diagrams or noting the change. If you accept a fundamental design change during Q&A but don’t update your artifacts, how does that cascade through the rest of your defense?”
What they’re testing: Whether you understand that accepting a design change during Q&A creates an obligation to trace that change through all affected artifacts. Testing the meta-skill of live architecture adaptation: when you concede a point, you must verbally update the dependent diagrams, security model, integration flows, and any other affected component. Failing to do so creates internal contradictions that judges will exploit in subsequent questions.
Model answer: “That is a critical observation, and you are right that I created a dangerous inconsistency. When I accepted the change to my sharing model, I should have immediately traced and verbally updated every dependent artifact before moving to the next question.
Let me do that now. The sharing model change from Public Read Only to Private on the Order object means three artifacts need verbal updates.
First, my System Landscape: the integration arrows from MuleSoft to the Order object now need an annotation noting that the Integration User requires ‘Modify All’ permission, because the default OWD no longer grants visibility.
Second, my Data Model: the ERD should reflect that the Order object now has its own independent OWD of Private rather than inheriting from a parent. If I had drawn it as a Master-Detail, I would need to flag that the sharing change might require converting to a Lookup.
Third, my Role Hierarchy diagram: I need to confirm that the VP of Sales sits high enough in the hierarchy to see all Orders through role-based sharing, or I need to add a sharing rule granting the VP’s public group explicit access.
The lesson here is that every concession during Q&A is not just an answer. It is an architectural change that must be traced through the full dependency chain. I will adopt the practice of saying ‘Let me trace that change through my artifacts’ every time I accept a correction, so the judges see I understand the cascading impact.”
Follow-up: “You have now verbally updated three artifacts. How do you keep track of all these live changes so you don’t contradict yourself in a later answer?”
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.