Modern Platform Features

The Salesforce platform evolves rapidly. A CTA must understand the latest capabilities, their maturity level, and when to use them vs 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 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 matters for designing OmniStudio solutions.

Figure 1. Integration Procedures are the central orchestrator in OmniStudio: FlexCards and OmniScripts call them for all backend logic, and they coordinate DataRaptors, Decision Matrices, Expression Sets, and external API calls. This separation mirrors an MVC pattern and keeps UI components free of business logic.

Component Interaction Pattern

The typical data flow: 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 mirrors 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 lacks OmniStudio licensing, or admin maintainability is the priority.

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 covers 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 their training data. 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 (formerly Tableau CRM) licensing

Agentforce Architecture

Agentforce (formerly Einstein Copilot) is Salesforce’s autonomous AI agent platform, letting organizations deploy AI agents that take actions within Salesforce.

Agentforce Components

Figure 2. All topics share a common actions library, so a Flow or Apex action built for one topic is reusable across others without duplication. The Trust Layer sits between execution results and the user response, applying guardrails regardless of which topic or action type was invoked.

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.

Figure 3. The RAG retrieval loop before plan generation is what separates Atlas from a simple LLM call: the engine can request additional data mid-reasoning if the initial context is insufficient. Actions execute deterministically inside Salesforce, grounding AI reasoning in real CRM state rather than training data assumptions.

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 360 (formerly Data Cloud)	Unified data layer powering RAG retrieval, now enhanced with Informatica	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), and the majority of LWC-enabled standard objects (Account, Contact, Opportunity, Case, Lead, and many more). Notable exceptions include Campaign, Task, and Product - check the Lightning App Builder for the Fields tab to confirm support on a given object.
• 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 let you register an external API (via OpenAPI/Swagger spec) and invoke it declaratively from Flow without writing Apex.

How External Services Work

Figure 4. External Services eliminates Apex callout code for simple REST APIs: registering an OpenAPI spec automatically generates typed invocable actions that admins can drag into Flow Builder. Named Credentials handle authentication, keeping endpoint URLs and tokens out of Flow logic and deployment-safe across environments.

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

Figure 5. Greenfield always means LWC. For Visualforce with a complex Apex controller, a phased migration preserves the backend investment while replacing only the presentation layer. Stable Aura components are kept to avoid rewrite risk, with new feature development going directly to LWC.

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.

Figure 6. LDS handles simple single-record CRUD with no Apex required, Wire Service provides reactive auto-refreshing data binding, and imperative Apex gives explicit control over when calls fire. Choosing the right pattern directly affects governor limit consumption and component re-render performance.

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	Maturing	Evaluate for customer service automation, sales, and commerce
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

Recommending a GA but early-maturity feature 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 Trailblazer Community: Best practices for technology selection