Modern Platform Features

The Salesforce platform evolves rapidly. A CTA must understand the latest capabilities, their maturity level, and when to leverage them vs when to use proven approaches. This page covers the modern platform features most likely to appear in CTA scenarios.

OmniStudio (formerly Vlocity)

OmniStudio is Salesforce’s industry-oriented low-code toolkit for building guided digital experiences. It is particularly relevant for industries like communications, insurance, healthcare, and financial services.

Core Components

Component	Purpose	Analogous To
OmniScript	Multi-step guided processes	Screen Flows (but more powerful UI)
DataRaptor	Data transformation and extraction	Flow Get/Create Records + formula logic
FlexCards	Context-aware UI cards	Lightning Record Pages (but dynamic)
Integration Procedures	Server-side orchestration	Apex classes for integration logic
Decision Matrices	Lookup-based decision tables	Custom Metadata + formula fields
Expression Sets	Complex calculation logic	Apex calculation engines

OmniStudio Architecture

OmniStudio operates across three layers: the frontend digital experience layer, the data orchestration layer, and the decision/calculation layer. Understanding how the components interconnect is key to designing OmniStudio solutions.

flowchart TB
    subgraph UILayer["Frontend — Digital Experience Layer"]
        direction LR
        FC["FlexCards<br/>(context-aware UI cards)"] --> OS["OmniScripts<br/>(guided multi-step processes)"]
    end

    subgraph DataLayer["Middle — Data Orchestration Layer"]
        direction LR
        IP["Integration Procedures<br/>(server-side orchestration)"] --> DR["DataRaptors"]
        DR --> DRE["Extract<br/>(read from SF)"]
        DR --> DRT["Transform<br/>(reshape data)"]
        DR --> DRL["Load<br/>(write to SF)"]
        DR --> DRTE["Turbo Extract<br/>(fast single-object read)"]
    end

    subgraph DecisionLayer["Backend — Decision & Calculation Layer"]
        direction LR
        DM["Decision Matrices<br/>(lookup tables)"] --> ES["Expression Sets<br/>(complex calculations)"]
    end

    subgraph External["External Systems"]
        direction LR
        API["REST/SOAP APIs"] --> EXT["Third-Party Systems"]
    end

    OS -->|"calls"| IP
    FC -->|"calls"| IP
    FC -->|"launches"| OS
    IP -->|"uses"| DM
    IP -->|"uses"| ES
    IP -->|"calls"| API
    IP -->|"orchestrates"| DR

    style UILayer fill:#e6f5f0,stroke:#2d6a4f
    style DataLayer fill:#eef0f5,stroke:#264653
    style DecisionLayer fill:#fef3e6,stroke:#f4a261
    style External fill:#fce4e4,stroke:#e76f51

Component Interaction Pattern

The typical data flow is: FlexCard displays summary data (read via DataRaptor Extract) and offers an action button that launches an OmniScript. The OmniScript collects user input across multiple steps, then calls an Integration Procedure to orchestrate the backend. The Integration Procedure uses DataRaptors to read/write Salesforce data, Decision Matrices for rule lookups, and Expression Sets for calculations. This separation of concerns is architecturally similar to an MVC pattern.

OmniScript vs Screen Flow

Factor	OmniScript	Screen Flow
UI Flexibility	Highly customizable, CSS themes	Limited to standard components
Multi-step forms	Native multi-step with branching	Requires multiple screens with navigation
Industry templates	Pre-built for specific industries	Generic, requires configuration
Learning curve	Steep — unique paradigm	Moderate — familiar Salesforce tooling
Maintenance	Requires OmniStudio expertise	Admin-friendly
Licensing	Industry Cloud or OmniStudio license	Included in most editions
Performance	Optimized for complex UIs	Good for simple-moderate UIs
Offline support	Limited	Not supported

CTA Decision Point

Choose OmniStudio when the scenario involves industry-specific processes (insurance quoting, telecom ordering, healthcare intake) or complex multi-step guided experiences with heavy data transformation. Choose Screen Flows when the process is straightforward, the customer does not have OmniStudio licensing, or admin maintainability is paramount.

DataRaptor Types

• Turbo Extract: Read-only, fastest for simple single-object queries
• Extract: Read with joins across multiple objects, formula support
• Transform: Data manipulation without reading or writing (reshape data)
• Load: Write data to Salesforce objects (insert, update, upsert)

Einstein AI Features

Einstein encompasses Salesforce’s AI capabilities. A CTA must understand what each tool does and when to recommend it.

Einstein Feature Matrix

Feature	What It Does	Data Needed	Use Case
Prediction Builder	No-code binary/numeric predictions	Historical outcome data	Lead conversion prediction, churn risk
Next Best Action	Recommendation engine with strategies	Business rules + predictions	Offer recommendations, case resolution
Einstein Bots	Conversational chatbots	FAQ data, knowledge articles	Customer self-service, case deflection
Einstein Activity Capture	Auto-log emails and events	Email/calendar integration	Activity tracking without manual entry
Einstein Lead Scoring	ML-based lead scoring	6+ months of lead data	Lead prioritization for sales
Einstein Opportunity Insights	Deal intelligence	Opportunity history	Risk identification, coaching
Einstein Search	Personalized search results	Usage patterns	Improved search relevance
Einstein for Service	Case classification and routing	Case history	Auto-classification, agent recommendations

Einstein Implementation Considerations

Data Quality Prerequisites

Einstein models are only as good as the data they are trained on. Before recommending Einstein features, validate that the customer has sufficient historical data (typically 6-12 months minimum), consistent data entry practices, and clean data. Without these prerequisites, Einstein will produce unreliable predictions.

Architectural Considerations:

• Einstein features consume additional API calls and storage
• Prediction models need retraining as business changes — plan for model governance
• Einstein Activity Capture stores data outside the Salesforce data model (Einstein Activity Platform)
• Some Einstein features require Shield or specific editions
• Custom models via Einstein Discovery require CRM Analytics (Tableau CRM) licensing

Agentforce Architecture

Agentforce represents Salesforce’s autonomous AI agent platform, allowing organizations to deploy AI agents that can take actions within Salesforce.

Agentforce Components

flowchart TD
    A[User Request] --> B[Agent Runtime]
    B --> C{Topic Classification}
    C --> D[Topic: Sales]
    C --> E[Topic: Service]
    C --> F[Topic: Custom]
    D --> G[Actions Library]
    E --> G
    F --> G
    G --> H[Flow Actions]
    G --> I[Apex Actions]
    G --> J[Prompt Templates]
    G --> K[API Actions]
    H --> L[Execute in Salesforce]
    I --> L
    J --> L
    K --> L
    L --> M[Guard Rails & Trust Layer]
    M --> N[Response to User]

    style B fill:#1a535c,stroke:#0d3b44,color:#fff
    style M fill:#e76f51,stroke:#c45a3f,color:#fff

Atlas Reasoning Engine — Deep Dive

The Atlas Reasoning Engine is the “brain” behind Agentforce. It implements System 2 reasoning — deliberate, step-by-step analysis rather than fast pattern matching. Understanding the reasoning loop is essential for designing effective agents.

flowchart TD
    A["User Query"] --> B["Topic Classification<br/>(match to defined topics)"]
    B --> C["RAG: Data Retrieval<br/>(Data Cloud, Knowledge, CRM)"]
    C --> D["Augmented Prompt Assembly<br/>(query + data + topic instructions + guardrails)"]
    D --> E["LLM Reasoning — Plan<br/>(chain-of-thought, step-by-step plan)"]
    E --> F{"Is the plan<br/>sufficient?"}
    F -->|"No — needs more data"| C
    F -->|"Yes"| G["Action Selection<br/>(choose Flow, Apex, API, or Prompt)"]
    G --> H["Action Execution<br/>(execute within Salesforce)"]
    H --> I["Observe Results"]
    I --> J{"Goal<br/>achieved?"}
    J -->|"No — refine"| E
    J -->|"Yes"| K["Self-Reflection & Validation<br/>(check against guardrails)"]
    K --> L{"Passes<br/>guardrails?"}
    L -->|"No"| M["Transfer to Human Agent"]
    L -->|"Yes"| N["Response to User"]

    N --> O["Feedback Loop<br/>(logged for improvement)"]

    style B fill:#264653,stroke:#1d3640,color:#fff
    style C fill:#2a9d8f,stroke:#21867a,color:#fff
    style E fill:#1a535c,stroke:#0d3b44,color:#fff
    style K fill:#e76f51,stroke:#c45a3f,color:#fff
    style M fill:#9d0208,stroke:#6a040f,color:#fff

The ReAct Loop: Atlas uses a Reason-Act-Observe cycle. The engine reasons about the problem, acts by executing tools, observes the result, and loops back to refine its plan. This continues until the goal is met or the engine determines a human handoff is needed.

Key Agentforce Concepts

Concept	Description	Architectural Significance
Topics	Categories scoping agent behavior (e.g., “Order Management”)	Narrows the reasoning problem, enforces business policies
Actions	Executable tasks (Flows, Apex, APIs, Prompt Templates)	Reuse existing automation — no new code needed for agents
Guardrails	Constraints on agent behavior and responses	Prevent policy violations regardless of user requests
Trust Layer	Data masking, toxicity detection, PII handling	Enterprise-grade AI safety built into the platform
Prompt Templates	Grounded prompts referencing Salesforce data	RAG-based, reducing hallucination with real data
Data Cloud	Unified data layer powering RAG retrieval	Zero-copy architecture preserves data governance

Agentforce vs Einstein Bots

Einstein Bots are rule-based with limited NLU. Agentforce agents use LLMs with reasoning capabilities and can take autonomous actions. For simple FAQ-style interactions, Einstein Bots may suffice. For complex, multi-step interactions requiring reasoning, Agentforce is the modern choice. In Salesforce’s CRMArena-Pro benchmarks, generic LLM agents achieved only ~33% accuracy on core CRM tasks. Agentforce pilot data shows approximately 2x improvement in response relevance over DIY AI solutions (per Salesforce marketing materials — not independently verified benchmarks).

Dynamic Forms and Dynamic Actions

Dynamic Forms and Dynamic Actions modernize the Lightning record page experience by decoupling fields and actions from the page layout.

Dynamic Forms

• What it does: Place individual fields and field sections anywhere on a Lightning record page, with visibility rules per field/section
• Supported objects: Custom objects (all), Standard objects (Account, Contact, Opportunity, Case, Lead, and more being added)
• Key benefit: Different users can see different fields on the same record page without multiple page layouts
• Replaces: Page layouts for field arrangement (page layouts still needed for related lists, compact layouts, mobile)

Dynamic Actions

• What it does: Control which action buttons appear on a record page based on criteria (field values, user profile, record type)
• Key benefit: Context-aware action buttons — show “Send for Approval” only when Status = Draft
• Replaces: Static page layout action sections

When to Recommend Dynamic Forms

Recommend Dynamic Forms	Stick with Page Layouts
Multiple user personas need different field visibility	Simple org with one user type
Complex conditional field display rules	Straightforward field display
Need to reduce page layout proliferation	Few record types
Want component-level field placement	Standard layouts sufficient
Lightning-only deployment	Classic or mixed Classic/Lightning

External Services

External Services allow you to register an external API (via OpenAPI/Swagger spec) and invoke it declaratively from Flow without writing Apex.

How External Services Work

flowchart LR
    A[OpenAPI Spec] --> B[Register in External Services]
    B --> C[Named Credential for Auth]
    C --> D[Invocable Actions Created]
    D --> E[Available in Flow Builder]
    E --> F[Call External API from Flow]

    style A fill:#4ecdc4,stroke:#3ab5ad,color:#000
    style D fill:#2d6a4f,stroke:#1b4332,color:#fff
    style F fill:#2d6a4f,stroke:#1b4332,color:#fff

When to use External Services:

• Simple REST API integrations (GET, POST, PUT)
• APIs with clean OpenAPI/Swagger documentation
• Admin-maintainable integration needs
• Low-to-moderate volume calls (not bulk operations)

When to use Apex instead:

• Complex request/response transformation
• Retry logic and circuit breaker patterns
• Bulk API operations
• APIs without OpenAPI specs
• Custom authentication flows

LWC vs Aura vs Visualforce

This is a perennial CTA topic. The technology choice depends on the use case, existing codebase, and team capabilities.

Decision Matrix

Factor	LWC	Aura	Visualforce
Performance	Best (web standards)	Good (framework overhead)	Adequate (server round-trips)
Development model	Modern JS, web standards	Proprietary framework	MVC, Apex controller
Component ecosystem	Growing, base components	Mature, large ecosystem	Legacy, full library
Mobile support	Native mobile support	Mobile support	Limited (Visualforce tabs)
Community/Experience Cloud	Full support	Full support	Limited to Visualforce pages
Flow embedding	Supported (Screen Flow)	Supported	Not directly
Lightning Out	Supported	Supported	N/A
Service Console	Full support	Full support	Visualforce tabs only
New feature development	Active (Salesforce focus)	Maintenance mode	No new investment
Staffing availability	Growing talent pool	Shrinking pool	Large legacy pool

Migration Considerations

flowchart TD
    A{What do you have<br/>today?} --> B[Visualforce Pages]
    A --> C[Aura Components]
    A --> D[Nothing - Greenfield]

    B --> E{Complex page<br/>with Apex controller?}
    E -->|Yes| F[Phased migration:<br/>VF → LWC with Apex backend]
    E -->|No| G[Direct rewrite to LWC]

    C --> H{Aura working well<br/>and stable?}
    H -->|Yes| I[Keep Aura, new<br/>features in LWC]
    H -->|No| J[Rewrite to LWC]

    D --> K[LWC - Always]

    style K fill:#2d6a4f,stroke:#1b4332,color:#fff
    style G fill:#2d6a4f,stroke:#1b4332,color:#fff
    style I fill:#f4a261,stroke:#d4823e,color:#000
    style F fill:#f4a261,stroke:#d4823e,color:#000

CTA Recommendation Pattern

For greenfield: always LWC. For existing Aura: keep Aura where it works, build new in LWC, migrate Aura to LWC opportunistically. For existing Visualforce: migrate to LWC where there is business value, do not migrate for migration’s sake.

LWC Component Architecture

Understanding LWC’s architecture helps CTAs explain why it performs better than Aura and how it fits into the broader Salesforce UI stack.

flowchart TB
    subgraph LWCStack["LWC Architecture Stack"]
        direction TB
        A["Lightning Web Component<br/>(HTML template + JS controller)"]
        B["LWC Engine<br/>(Web Standards: Custom Elements, Shadow DOM, Templates)"]
        C["Lightning Data Service (LDS)<br/>(client-side cache, CRUD without Apex)"]
        D["Wire Service<br/>(reactive data binding to Apex or LDS)"]
        E["Base Lightning Components<br/>(lightning-input, lightning-datatable, etc.)"]
    end

    subgraph DataAccess["Data Access Patterns"]
        direction LR
        F["LDS — No Apex Needed<br/>(getRecord, createRecord, updateRecord)"]
        G["Wire Adapter — Declarative<br/>(@wire with Apex method)"]
        H["Imperative Apex<br/>(called from JS handler)"]
    end

    subgraph Composition["Component Composition"]
        direction LR
        I["Parent LWC<br/>(passes data via @api)"] --> J["Child LWC<br/>(fires CustomEvent up)"]
        I --> K["Child LWC<br/>(sibling communication via pub/sub or LMS)"]
    end

    A --> B
    A --> C
    A --> D
    A --> E
    C --> F
    D --> G
    A --> H

    style LWCStack fill:#e6f5f0,stroke:#2d6a4f
    style DataAccess fill:#eef0f5,stroke:#264653
    style Composition fill:#fef3e6,stroke:#f4a261

CTA Data Access Decision

Use Lightning Data Service when you need simple CRUD on a single record (no Apex needed). Use Wire Service when you need reactive data from Apex that refreshes automatically. Use Imperative Apex when you need control over when the call happens (e.g., on button click with error handling). This decision directly impacts performance and governor limit consumption.

Aura-LWC Interoperability

• LWC can be embedded in Aura components (child)
• Aura can wrap LWC components (parent)
• They can communicate via events and public properties
• This enables gradual migration without full rewrites
• Aura components cannot be embedded in LWC

Feature Maturity Assessment

When recommending modern features, assess their maturity:

Feature	GA Status	Maturity	CTA Recommendation
LWC	GA	Mature	Default for all new UI development
Screen Flows	GA	Mature	Default for guided processes
OmniStudio	GA	Mature (Industries)	When industry templates add value
Dynamic Forms	GA	Maturing	Recommended for complex page layouts
External Services	GA	Mature	Simple integrations without Apex
Agentforce	GA	Early	Evaluate for customer service automation
Einstein Prediction Builder	GA	Mature	When historical data supports predictions
Einstein Bots	GA	Mature	Proven for case deflection
Flow Orchestration	GA	Maturing	Multi-step, long-running processes

Early-Maturity Features in CTA Scenarios

In a CTA scenario, recommending a feature that is GA but early-maturity is acceptable if you acknowledge the risk and include a mitigation strategy. For example: “I recommend Agentforce for the customer service use case, with a phased rollout starting with a single topic and expanding based on measured deflection rates. If adoption is slower than expected, the existing case routing Flow remains the fallback.”

Related Topics

• Declarative vs Programmatic — Flow vs Apex decision framework
• Build vs Buy — When to use AppExchange vs custom build
• Decision Guides — Visual decision flowcharts for all technology choices
• Trade-Offs — Customization vs configuration analysis
• Integration — Integration patterns that interact with these features

Sources

• Salesforce Architects: OmniStudio Architecture
• Salesforce Developer Documentation: Lightning Web Components Guide
• Salesforce Help: Dynamic Forms
• Salesforce Help: External Services
• Salesforce Developer Documentation: Einstein Platform
• Salesforce Agentforce Documentation: Agentforce Overview
• Salesforce Engineering: Inside the Brain of Agentforce — Atlas Reasoning Engine
• Salesforce: How the Atlas Reasoning Engine Powers Agentforce
• Cirra AI: Salesforce Atlas Explained — How the AI Reasoning Engine Works
• Salesforce Ben: Introducing Atlas: The Brain Behind Agentforce
• Salesforce Developers Blog: What’s New in OmniStudio Standard Designers
• Salesforce Trailhead: Build LWC Modules
• CTA Study Groups: Community best practices for technology selection