Solution Architecture

Key Takeaways

Solution Architecture requires picking the right blend of declarative and programmatic capabilities while evaluating build-vs-buy trade-offs. Know when to reach for Flow vs Apex, how to evaluate AppExchange packages with a TCO framework, and how modern platform features like Agentforce (formerly Einstein Copilot), OmniStudio, and Dynamic Forms shift architectural decisions.

This domain covers selecting the right combination of declarative and programmatic functionality and evaluating external applications.

Objectives

• Appropriate combination of declarative and programmatic functionality
• Benefits, considerations, and trade-offs of incorporating external applications

Study Content

Core Topics

• Declarative vs Programmatic Solutions: Flow Builder vs Apex, automation strategy, order of execution, governor limits, and when to use each
• Build vs Buy & AppExchange Strategy: AppExchange evaluation framework, managed package considerations, TCO analysis, vendor scorecard, exit strategies
• AppExchange & ISV Landscape: Key ISV solutions by category (document gen, backup, data quality, DevOps, payments, CTI, iPaaS), vendor comparison tables, CTA scenario patterns
• Modern Platform Features: OmniStudio, Einstein AI, Agentforce, Dynamic Forms, External Services, LWC vs Aura vs Visualforce
• Agentforce Architecture: Atlas Reasoning Engine, Agent Builder, topics and actions, Trust Layer, Data Cloud grounding, deployment patterns, CTA scenario guidance

Product, Pricing & Commerce Architecture

• CPQ Architecture: Data model, pricing waterfall, rules engine, Advanced Approvals, CPQ vs Revenue Cloud, performance at scale, CTA scenario patterns
• Commerce Architecture: B2C vs B2B vs B2B2C, headless/composable commerce, Order Management, integration patterns, CTA commerce scenarios

Decision Guides & Analysis

• Decision Guides: Mermaid decision flowcharts for Flow vs Apex, build vs buy, LWC vs Aura, OmniStudio vs Flow, Screen Flow vs LWC
• Trade-Offs: Declarative vs programmatic, native vs AppExchange, configuration vs customization analysis
• Best Practices: Solution architecture patterns, anti-patterns, and design principles

Practice

• Domain Grilling: D4 Solution Architecture Q&A

Key Exam Focus Areas

• Declarative-first as a default, not dogma. The board does not reward candidates who call Flow “always better.” They reward candidates who can say: “I chose Flow because this logic is simple CRUD with predictable volume, the admin team can maintain it, and the governor limit profile is favorable — but I chose Apex for the high-volume integration handler because Flow’s shared CPU ceiling would be exceeded in bulk operations.” Always lead with Flow, then justify the escalation to code with specifics.

• AppExchange evaluation requires a structured scorecard. Saying “I’d recommend DocuSign because it’s popular” fails. The expected pattern is: define the capability gap, evaluate 3+ options, score each against weighted criteria (functionality, technical fit, vendor stability, upgrade path, exit strategy, compliance), and present the recommendation with the trade-offs explicitly named. A vendor scoring below 70% on the weighted scorecard is a signal that custom development carries less long-term risk.

• Build vs buy goes beyond license cost. TCO is the frame. The 3-year crossover dynamic — where custom solutions often become more expensive than AppExchange packages due to accumulated technical debt and developer turnover — is a board-level insight. Present Year 1 cost and 5-year cost separately. License escalation (5-8% annually) must appear in the buy-side projection.

• Managed packages have architectural footprint. Governor limits, namespace overhead, upgrade risk, and data model implications are all part of the AppExchange evaluation. Certified managed packages get separate SOQL and DML allocations per namespace, but CPU time and heap are shared. A complex package like OmniStudio or CPQ can consume a significant portion of available limits in a transaction, which must be factored into the overall automation design.

• Order of execution is a decision variable, not just trivia. Before-save flows can modify the triggering record with zero DML cost — using after-save for the same work is a governor limit mistake. Workflow field updates trigger an additional before-and-after trigger cycle, which cascades limit consumption. Roll-up summary field updates cascade the full execution chain onto the parent object. Knowing where each automation fires shapes the design of the automation layer.

• OmniStudio is a real decision alternative. For Industries cloud scenarios (communications, insurance, financial services, healthcare), OmniScript is frequently the correct answer over Screen Flow. OmniStudio’s three-layer architecture — FlexCards and OmniScripts at the UI layer, Integration Procedures orchestrating the middle, DataRaptors handling data transformation — needs to appear in your solution vocabulary.

• Agentforce has architectural prerequisites. Any Agentforce recommendation must address the Atlas Reasoning Engine, Trust Layer guardrails, Data Cloud grounding for retrieval-augmented generation, and the build-out effort for topics and actions. Recommending Agentforce without addressing these signals shallow platform knowledge to the board.

• Exit strategy is not optional. Every AppExchange recommendation should include data portability assessment, contractual termination terms, and at minimum one named alternative. The board looks for risk-aware thinking — a candidate who plans for failure demonstrates maturity that candidates who assume the happy path do not.

Related Topics

Solution design requires balancing capabilities across multiple domains at once:

• System Architecture: The org strategy (single vs multi-org, edition choice, license allocation) sets hard constraints on which solution patterns are available. A Domain 4 recommendation that requires features unavailable in the customer’s edition fails immediately.

• Security Architecture: Every solution pattern must work within the sharing model. Apex Managed Sharing decisions, profile and permission set structures, and compliance requirements (GDPR, HIPAA, PCI) eliminate some build options entirely and mandate others.

• Data Architecture: Solution design drives the data model. Object choices ripple into LDV risk, reporting performance, archival strategy, and data migration sequencing. A Domain 4 solution that creates an LDV risk on a junction object without addressing it in Domain 3 will be caught by the board.

• Integration Architecture: Solution boundaries determine what Salesforce owns vs external systems. The API volume and pattern (real-time vs batch, point-to-point vs middleware-mediated) shapes whether External Services, Apex callouts, or a dedicated integration platform is the right tool.

• Development Lifecycle: Team skills (admin-heavy vs developer-centric), CI/CD pipeline maturity, release cadence, and sandbox strategy directly influence whether declarative or programmatic solutions are operationally sustainable. The board expects your Solution Architecture recommendation to account for who can maintain it after go-live.

Frequently Asked Questions

What does the CTA exam test in Solution Architecture?

The exam tests your ability to select the right combination of declarative and programmatic functionality, evaluate build-vs-buy decisions with TCO analysis, assess AppExchange packages against custom development, and apply modern platform features like Agentforce, OmniStudio, and Dynamic Forms. You must justify why your chosen approach beats the alternatives.

How is Solution Architecture scored in the CTA review board?

Judges evaluate whether you follow a declarative-first approach with justified exceptions, whether your build-vs-buy analysis considers total cost of ownership (not just license cost), whether you show awareness of modern platform capabilities, and whether you can articulate trade-offs between your chosen solution components and the alternatives.

What are the most common mistakes in Solution Architecture during the CTA exam?

Candidates commonly fail by jumping to Apex when Flow Builder would work, skipping a build-vs-buy analysis for AppExchange packages, ignoring exit strategy risks with third-party managed packages, overlooking OmniStudio or Agentforce for guided processes, and not addressing order of execution when combining declarative and programmatic automation.

How should I approach build-vs-buy decisions at the review board?

Apply a structured evaluation framework: assess the requirement fit, evaluate vendor stability and roadmap, calculate TCO over 3-5 years (license + implementation + maintenance + training), consider exit strategy and data portability, evaluate managed package governor limit impact, and weigh the team’s ability to maintain custom code vs configure a package. Present at least two options with clear trade-offs.

When should I recommend Agentforce in a CTA scenario?

Recommend Agentforce when the scenario describes repetitive customer or employee interactions that follow predictable patterns, mentions reducing case volume or agent workload, or requires intelligent automation grounded in the organization’s data. Address the Atlas Reasoning Engine, Trust Layer for hallucination prevention, Data Cloud grounding requirements, and the build-out effort for topics and actions.