Skip to content
theCodeFlash

Solution Architecture Decision Guides

These decision flowcharts cover the most common solution architecture choices a CTA faces. They can be referenced during scenario analysis and walked through at the Review Board to show systematic reasoning.

Flow vs Apex Decision

Declarative vs Programmatic. The scenario usually contains a volume indicator, a complexity indicator, and a team profile indicator. Simple field updates on a triggering record with predictable volume and an admin-heavy team points to Before-Save Flow. Logic involving complex data transformations (nested loops, maps, set operations), high volume (50K+ records), or external callouts with retry requirements points to Apex. The critical wrong pattern is what candidates do between those extremes: they guess. The correct pattern is to walk through the invocable action bridge — can the complex logic be encapsulated in a tested Apex method and exposed as an invocable action, keeping Flow as the orchestration layer? If yes, that hybrid usually wins in scenarios where admin maintainability matters.

Determines whether a given automation requirement should be implemented declaratively (Flow) or programmatically (Apex).

Routes any automation requirement through record scope, volume, callout type, and user interaction checks to the most appropriate Salesforce tool.
Figure 1. The 50K record threshold is the key volume gate: below it an After-Save Flow is viable, above it Batch Apex is mandatory. The OpenAPI spec check separates External Services (no-code callouts) from full Apex callouts requiring retry logic and custom error handling.

Legend: Green = Declarative (admin-maintainable) | Orange = Hybrid | Red = Programmatic (developer-required)

Build vs Buy Decision

Build vs Buy. The evaluation must be multi-dimensional and structured. The wrong reasoning is “AppExchange is faster, so we buy.” The right reasoning applies the full spectrum: is this capability available platform-natively (use it)? Is it a commodity capability with established market leaders (evaluate AppExchange)? Is it core to competitive advantage (build custom)? Scoring the short-listed AppExchange option against the weighted vendor scorecard — with explicit attention to exit strategy, upgrade path, and governor limit footprint — is what separates a CTA-level recommendation from a partner sales pitch. The board specifically probes what you gave up and under what conditions you would revisit the decision.

Evaluates whether to build a capability custom, use an AppExchange package, or use an external product.

Evaluates competitive advantage, team skills, AppExchange package maturity, and 3-to-5-year TCO before committing to build, buy, or external product.
Figure 2. Competitive advantage is the pivotal fork: capabilities that differentiate the business warrant custom build even when AppExchange options exist. For non-differentiating capabilities, the 80% fit threshold and 3-5 year TCO check prevent over-investing in packages that require heavy customization to close gaps.

Legend: Green = Platform Native | Teal = AppExchange | Orange = External Product | Red = Custom Build

AppExchange Evaluation Decision

AppExchange Package Selection. Common errors: evaluating only on functionality (ignoring vendor stability, upgrade risk, and data residency), missing the governor limit impact analysis (especially for packages that add triggers to standard objects), and forgetting to model the exit strategy. The 70% weighted scorecard threshold is the decision gate. Below it, the governance burden of configuring around gaps and managing upgrade risk exceeds the benefit of out-of-box functionality, and custom development becomes the defensible recommendation.

Used after identifying an AppExchange package to determine whether it is the right choice.

Sequential go/no-go gates covering security review, active development, functional fit, governor limit impact, data model, upgrade path, and vendor stability.
Figure 3. Four hard stops prevent adoption of packages that fail security review, functional fit, governor limit, or data model gates. Vendor financial instability and unclear upgrade paths do not block adoption outright but require documented mitigations before recommending to the review board.

LWC vs Aura vs Visualforce Decision

Guides UI technology selection for a new component or migration of an existing one.

Guides new builds to LWC and routes existing Visualforce and Aura components through stability and business-value checks before migration decisions.
Figure 4. All new UI development goes directly to LWC. Stable, working Visualforce or Aura components are kept unless there is clear business value in migrating, preventing expensive rewrites that deliver no user-facing improvement while consuming developer capacity.

Key Principle

Never migrate for migration’s sake. The review board values pragmatic architecture. Migrating a stable Visualforce page that 5 users access monthly is a poor use of resources compared to building new capabilities in LWC.

OmniStudio vs Standard Flow Decision

Determines whether OmniStudio components add enough value over standard Flow/LWC approaches.

Determines whether a guided process warrants OmniStudio based on industry licensing, UI complexity, data transformation needs, and team expertise.
Figure 5. OmniStudio is justified when Industry Cloud licensing is already in place and industry templates reduce build time, or when UI complexity genuinely exceeds Screen Flow capabilities. Without existing licensing, the ROI check prevents adding OmniStudio costs for processes a Screen Flow with custom LWC could handle.

Legend: Dark Teal = OmniStudio | Green = Standard Flow | Orange = Hybrid (Flow + LWC)

Screen Flow vs Custom LWC Decision

Determines whether a user-facing requirement should be a Screen Flow or a custom LWC application.

Determines whether a user-facing requirement should use Screen Flow, a hybrid Flow plus embedded LWC, or a fully custom LWC application.
Figure 6. Admin maintainability after go-live is the primary fork: if admins must own it, Screen Flow is strongly preferred. The hybrid approach embeds a single custom LWC for one complex section while keeping the flow orchestration admin-controlled, balancing capability with operational sustainability.

Legend: Green = Screen Flow (admin-maintainable) | Orange = Hybrid | Red = Custom LWC (developer-required)

Agentforce vs Traditional Automation Decision

Determines whether Agentforce (formerly Einstein Copilot) fits a customer scenario, or whether traditional automation (Flow/Apex/Einstein Bots) is the better choice.

Routes customer interaction automation by NLU requirement, multi-step reasoning need, Data Cloud availability, and existing action reusability.
Figure 7. Data Cloud availability is the pivotal gate for full Agentforce deployment: without it, advanced RAG grounding is unavailable and Flow plus Apex is the safer choice. Reusing existing Flows and Apex as agent actions significantly reduces the Agentforce build cost and time to first value.

Legend: Green = Traditional Automation | Teal = Einstein Bots | Dark Teal = Agentforce | Orange = Hybrid/Phased

Agentforce Readiness Check

Before recommending Agentforce in a CTA scenario, verify three prerequisites: (1) the customer has or will invest in Data Cloud for grounded retrieval, (2) existing Flows and Apex can be exposed as agent actions, and (3) the use case genuinely benefits from multi-step reasoning rather than simple rule-based automation. Recommending Agentforce for a use case that a Screen Flow could handle signals over-engineering.

Automation Tool Selection (Full Range)

Covers choosing from all Salesforce automation tools, including modern features.

Covers the complete automation tool range from Agentforce and Einstein Bots through Flow types, OmniScript, Flow Orchestration, and Batch Apex.
Figure 8. A single decision tree spanning the full Salesforce automation spectrum, from AI-powered agents down to simple Autolaunched Flows. Use this at the review board to show systematic evaluation of all available tools before justifying the chosen approach.

Legend: Green = Declarative | Dark Teal = AI-Powered | Teal = Einstein Bots | Orange = Hybrid | Red = Programmatic

How to Use These Guides in a CTA Scenario

  1. Identify the decision point in the scenario requirements
  2. Walk through the relevant flowchart step by step
  3. Document your path through the flowchart in your presentation notes
  4. Present the decision to the review board by explaining which questions you asked and how the answers led to your recommendation
  5. Acknowledge the trade-offs of the path not taken

Review Board Strategy

A systematic decision framework shows architectural maturity. When a judge asks “Why did you choose X over Y?”, walk them through the decision tree instead of giving an ad-hoc justification.

Sources

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.