# architect Decision Guides - Full Documentation

<!-- document id=31c359b3587d61dfd9617bf7d6a304c5355d4dbd55de36417157dd3364761f48 url=/architect/next/en-us/decision-guides/guides/async-processing.md -->

# Asynchronous Processing

Use this guide to choose the right Salesforce asynchronous processing approach for each use case.

## Guide Overview

This guide will help you evaluate the right approach for your asynchronous processing requirements on the Salesforce platform. It explains each approach, detailing the strengths and limitations of each. Most approaches are aligned with a product feature, but some approaches use multiple features in coordination. The guide includes use cases to highlight when to use each approach.

Asynchronous processing provides two major benefits for your architecture. First, it increases scalability because asynchronous processes have higher governor limits. Second, asynchronous requests execute in their own threads so users can do other work while the asynchronous tasks execute in the background.

Note that this guide focuses exclusively on choosing an asynchronous processing technology within the Salesforce Platform. Other resources to help your decision process are listed in the [Resources section](#resources).

## Products in Scope for this Guide

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td>The <a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a> is a comprehensive, AI-driven platform that unifies employees, autonomous AI agents, company data, and applications into a single, trusted system to enhance productivity and customer experience. It enables the creation of an "agentic enterprise" by connecting Customer 360 apps, Data Cloud, and Slack for end-to-end automation.</td>
    </tr>
  </tbody>
</table>

This document does not cover technologies in other ecosystems such as MuleSoft, Informatica, Commerce Cloud, Tableau, and Marketing Cloud.

## Takeaways

- **Before using asynchronous processing, make sure that your use cases fit the pattern.** Asynchronous patterns have no SLA, are subject to multiple governor mechanisms, can have capacity limits defined based on licensing, and can cause processing delays due to the finite nature of the resources allocated to asynchronous infrastructure within the Salesforce Platform. Consider these limitations when using asynchronous processing in scenarios where a user requires a response from the system before they can continue with their work.
- **Asynchronous processing with Salesforce isn’t a solution for boundless scaling needs.** The Salesforce Platform doesn’t scale infinitely, and asynchronous patterns are subject to limitations. Asynchronous processing uses threads, which contain the contextual information that a CPU needs to execute a stream of instructions. Threads can run in parallel. The number of available threads in any CPU is limited, so the platform has mechanisms in place to use its available threads as efficiently as possible. The platform’s [flow control mechanism](/docs/architect/fundamentals/guide/async-fundamentals#flow-control) prevents orgs from consuming too many threads and negatively affecting other orgs. The platform’s [fair usage algorithm](/docs/architect/fundamentals/guide/async-fundamentals#fair-usage) also controls the number of threads that an org has available for each particular message type.
- **Account for events that can cause extreme loads.** When you design asynchronous processes, make sure they can predictably manage workload spikes and lulls. Consider how your implementation handles unexpected events, such as power outages, and design safeguards that mitigate data loss or loss of functionality.

## Product Comparison

This table outlines the tools that are available for asynchronous processing with Salesforce. Refer to this table to review each tool’s major characteristics during your decision-making process. See [Use Cases](#use-cases) and [Decision Points](#decision-points) for help choosing the right tools for your architecture.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>Approach</th>
      <th>Description</th>
      <th>Skills Required</th>
      <th>Licenses and Limits</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Queueable Apex</b></td>
      <td>Use for processes that involve long-running database operations or external web service callouts. Queueable Apex offers features such as job IDs, support for non-primitive types, and job chaining.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">The number of licenses can increase the limits.</a></td>
    </tr>
    <tr>
      <td><b>Batch Apex</b></td>
      <td>Build complex, long-running processes that involve millions of records by dividing your record set and processing it in manageable chunks.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">The number of licenses can increase the limits.</a></td>
    </tr>
    <tr>
      <td><b>Scheduled Apex</b></td>
      <td>Execute Apex at a scheduled time defined by a cron expression. Although the act of scheduling Apex via the cron expression is an asynchronous process, the underlying code executes synchronously when the job starts.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">The number of licenses can increase the limits.</a></td>
    </tr>
    <tr>
      <td><b>Apex Continuation Callouts</b></td>
      <td>Execute callouts from Apex methods running in a synchronous transaction context.</td>
      <td>Pro-code</td>
      <td>No</td>
    </tr>
    <tr>
      <td><b>Asynchronous Path (Record-Triggered Flows)</b></td>
      <td>Execute an operation that you want to run on its own time. Avoid mixed DML errors that occur when you update a value on a related record that isn’t part of the record that triggered a flow.</td>
      <td>Low-code</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">The number and type of licenses can increase the limits.</a></td>
    </tr>
    <tr>
      <td><b>Scheduled Path (After Commit Flows)</b></td>
      <td>Execute at a dynamically scheduled time after a triggering event, such as when a record is created, updated, or deleted.</td>
      <td>Low-code</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">The number and type of licenses can increase the limits.</a></td>
    </tr>
    <tr>
      <td><b>Scheduled Flows</b></td>
      <td>Execute a flow in the background at a specified time and at a repeated frequency (daily, weekly, or once) to perform actions on a batch of records.</td>
      <td>Low-code</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">The number and type of licenses can increase the limits.</a></td>
    </tr>
    <tr>
      <td><b>Platform Event Triggers</b></td>
      <td>Loosely couple Salesforce with external systems and communicate between asynchronous components within the Salesforce Platform.</td>
      <td>Low-code + Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">An add-on license is required for high-volume platform event use cases</a></td>
    </tr>
    <tr>
      <td><b>Change Data Capture</b></td>
      <td>Capture and process change events asynchronously after the database transaction is committed.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">An add-on license is required to scale above baseline allocation.</a></td>
    </tr>
    <tr>
      <td><b>Bulk API</b></td>
      <td>Insert, update, upsert, query, or delete many records asynchronously and process the results later.</td>
      <td>Pro-code</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">There are limits.</a></td>
    </tr>
    <tr>
      <td><b>Lightning Actions</b></td>
      <td>Allow Lightning pages to interact with the server without forcing users to fully refresh the page.</td>
      <td>Low-code</td>
      <td>No</td>
    </tr>
  </tbody>
</table>

## Decision Points

This table contains an overview of points to consider as you decide which asynchronous tool to use.

<table>
  <tbody>
    <tr>
      <td><b>Skills Required</b></td>
      <td>Some of the tools outlined in this guide require code, while others can be configured declaratively. As you consider your options, think about the skillsets that your team members have. Keep in mind that even if developers are available for your initial implementation (through an implementation partner, for example), you may need to modify your solutions in the future. If your maintenance team lacks developers, a low-code option can be a better fit.</td>
    </tr>
    <tr>
      <td><b>Type of Platform Limits Enforced</b></td>
      <td>Determine the type of <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">limits</a> that apply to the execution. As you design your solutions, think carefully about how the volume and frequency of transactions will count toward the governor limits for the chosen approach each day. Calculate the number of executions that will occur each day. Make sure that the calculated values fall within the limits associated with your selected tools.</td>
    </tr>
    <tr>
      <td><b>Latency</b></td>
      <td>Determine how quickly the results of processing will be available in the platform. For some approaches, the changes will be nearly immediate, whereas for others it may be minutes or hours.</td>
    </tr>
  </tbody>
</table>

## Use Cases

When you select a tool for asynchronous processing, first evaluate your organization’s requirements and available resources. Your goal is to select the tool or tools that minimize implementation and maintenance costs, but still ensure scalability and minimize your likelihood of limit violations. This goal is dependent on the technical considerations outlined previously, as well as the makeup of your team.

Consider an asynchronous ordering process in Salesforce. When an order is saved, it triggers a message to an external warehouse management system with special instructions for how to pack and ship an item. The user who places the order doesn’t need an immediate response from the warehouse management system, so the request can be sent asynchronously. The asynchronous processing allows the user to continue their work without waiting for a response.

For this use case, you might consider implementing with Apex. This approach will only work if you have Apex developers on your team who can maintain your pro-code solution. Otherwise, a declarative approach makes more sense. Also, keep in mind that different sets of [limits](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) apply to different tools.

This table lists common use cases in the left-most column, followed by a description. The _First Choice_ column provides the most typical approach used to satisfy such a use case, along with the rationale for the First Choice approach. Use this as a starting point in your analysis—the First Choice approach may have limitations that will not work for your use case.

<table>
  <thead>
    <tr>
      <th>Use Case</th>
      <th>Description</th>
      <th>First Choice Approach</th>
      <th>Rationale</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>High-performance batch processing</b></td>
      <td>Any automation that must process thousands or millions of records efficiently</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex provides rich APIs for interfacing with the platform and for raw speed.</td>
    </tr>
    <tr>
      <td><b>Data Cleansing Job</b></td>
      <td>A job that runs routinely, or on demand, that cleans data. Examples include de-duplication, address verification, or data consolidation.</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex provides rich APIs for interfacing with the platform and for raw speed.</td>
    </tr>
    <tr>
      <td><b>Nightly Rollup Job</b></td>
      <td>Job that computes rollup data at the end of a business day.</td>
      <td>Batch <b>Apex</b></td>
      <td>Batch Apex provides rich APIs for interfacing with the platform and for raw speed.</td>
    </tr>
    <tr>
      <td><b>Record-Triggered Logic</b></td>
      <td>Execute logic in response to a record update.</td>
      <td><i>Varies</i></td>
      <td>See our companion decision guide, <a href="/docs/architect/decision-guides/guide/record-triggered">Record Triggered Events Automation</a>. It includes a decision tree for asynchronous use cases, including Queueable Apex, Batch Apex, Scheduled Apex, Scheduled Flow, Async Path Flows, and Change Data Capture.</td>
    </tr>
    <tr>
      <td><b>Cascading Updates Through an Object Graph</b></td>
      <td>Allows a user’s save action to complete quickly, deferring cascading updates to other objects to run asynchronously.</td>
      <td>Queueable <b>Apex</b></td>
      <td>Queueable Apex has powerful chaining features that enable logic to divide a chain of updates into a series of asynchronous transactions.</td>
    </tr>
    <tr>
      <td><b>Record-Specific Scheduled Processing</b></td>
      <td>Automation at a future, dynamic date specific to the record (for example, 3 days before a close date).</td>
      <td><b>Flow</b> with a Scheduled Path</td>
      <td>Scheduled paths provide a unique strength to Flow, as the platform automatically handles the scheduling, cancellation, and rescheduling of these paths if the record's data changes.</td>
    </tr>
    <tr>
      <td><b>Invoking Multiple Slow External Services in Parallel</b></td>
      <td>During a synchronous execution, multiple external services are invoked in parallel to optimize overall execution time.</td>
      <td><b>Apex</b> Continuation Callouts</td>
      <td>Allowing multiple slow-running callouts to run in parallel minimizes the overall time to complete the work.</td>
    </tr>
    <tr>
      <td><b>Data Migration of Records from an External System</b></td>
      <td>Move large amounts of records into the Salesforce Platform from an external system. Either a one-time or regularly scheduled process.</td>
      <td><b>Bulk</b> <b>API</b></td>
      <td>This is the most efficient and limit-friendly approach for data migration.</td>
    </tr>
    <tr>
      <td><b>Execute Additional Logic on an External System</b></td>
      <td>Fire-and-forget pattern of notifying an external system of an event on the platform, then allowing that system to asynchronously process the event.</td>
      <td><b>Platform Events</b> or <b>Change Data Capture</b></td>
      <td>A pub-sub model works best here, and allows the external system to process the event when it is ready. See <a href="/docs/architect/decision-guides/guide/event-driven">Event-Driven Architecture</a> for more details on this pattern.</td>
    </tr>
  </tbody>
</table>

The Use Cases table is a guide toward the best-fit approach for each use case. However, you’ll need to validate how well the First Choice technology fits the specific needs of your use case. In particular, determine whether the chosen approach can adhere to the governor limits for your org.

Once you have identified a candidate approach for your use case, the [Asynchronous Processing Fundamentals Guide](/docs/architect/fundamentals/guide/async-fundamentals) can assist in fully vetting the solution.

## Resources

These additional resources can help with your decision process:

- Deep dive into each of the platform asynchronous technologies: [Asynchronous Processing Fundamentals](/docs/architect/fundamentals/guide/async-fundamentals)
- Choosing between Apex and Flow for record triggers: [Record-Triggered Events Automation](/docs/architect/decision-guides/guide/record-triggered)
- Information about asynchronous integration patterns: [Event-Driven Architecture](/docs/architect/decision-guides/guide/event-driven)

<!-- document id=803deeb633155a95ee7eb066306f929d71023b873d48e6cafe19bfc5b815512c url=/architect/next/en-us/decision-guides/guides/build-forms.md -->

# Building Forms

There are multiple options for building forms on the Agentforce 360 Platform, and they span a continuum from low-code to pro-code approaches. On one end of the continuum, Dynamic Forms in Lightning App Builder and screen flows in Flow Builder can be used for low-code solutions. On the other end, the Lightning Web Component (LWC) framework is used for pro-code solutions. Within the continuum, tools can be blended in a number of ways using screen flows that are extended by LWCs and customer-facing forms that are built using Omnistudio.

## Guide Overview

This guide presents a decision framework and guidance on building forms for UI solutions. Specifically, it uses a dozen runtime and non-functional decision points to properly select the best technology for a given use case.

## Takeaways

- **When you’re building create/edit/view layouts for Lightning pages, use Dynamic Forms.** Moving forward, we recommend using _Dynamic Forms_ in _Lightning App Builder_ to configure record detail pages.

- **If you need to build, create, or edit a form for one object, use _Lightning Pages_ and _Dynamic Forms_.** This is the easiest way to build forms on the Agentforce 360 Platform. It also provides additional functionality (for example, field visibility control).

- **If you’re building a multi-page form or a wizard and you don’t have strict UX or branding requirements, use a Screen Flow.** Screen Flows provide a linear navigation framework for orchestrating multiple forms. You can use LWCs to construct your own framework for navigating between forms, but we recommend letting Flow do the work so that you can focus on the forms themselves rather than focusing on the form state.

- **If you need additional logic or actions to support the form, use a Screen Flow, Omnistudio, or LWCs.** Each of these tools offers different ways to enhance your solution by allowing it to expand beyond creating or editing a single record. In this instance, the term _more_ may refer to advanced logic (for example, branching or iteration), or it may refer to actions like integrating with external systems, sending emails, or pushing notifications to a user’s mobile app.

- **If you have sophisticated UX requirements, or if you need to dynamically manage more than UI visibility, use LWC or Omniscript.** For requirements that can be met by using theming and column-based layouts, you can build your forms directly in a low-code builder. However, granular control over your form’s style requires the flexibility of LWC. If you’re an Industries customer—and you need pixel-perfect branding or you have complex hierarchical data—use Omnistudio, which allows you to build consumer-grade forms that can handle complex business logic and data transformations.

- **If you need to deploy test automation, use LWC.** You can write unit tests for any LWC, regardless of where you embed it. This provides the ability to create a more robust test strategy, which may include bulk testing with multiple records, as well as negative testing.

- **You aren’t bound by “either/or” decisions.** You can combine multiple options to reach the best solution for your use cases (for example, if you need Flow’s built-in navigation system and the full styling flexibility that LWC offers, you can use them together).

## Tools in Scope

The following tools are commonly used to implement and extend form experiences.

### Tool Descriptions

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Dynamic Forms</th>
<th colspan="1" rowspan="1"><a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_migrate.htm&language=en_US&type=5">Dynamic Forms</a> in <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Salesforce Lightning App Builder</a> break down monolithic Record Detail components into individual, configurable fields and sections. This feature allows admins to create flexible, high-performance pages by placing fields anywhere, and using visibility rules to show or hide components based on user profile, device, or data, which helps reduce page clutter.</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">A Salesforce <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">Screen Flow</a> is an interactive automation tool within <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Flow Builder</a> that requires user input to move through customized, step-by-step business processes. Unlike automated background flows, Screen Flows provide a wizard-like user interface to collect data, display information, or perform actions via <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_page_overview.htm&type=5">Lightning Pages</a>, buttons, or custom apps without writing code.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omnistudio_standard.htm&type=5">Omnistudio</a> is a low-code suite of tools that are designed to rapidly build guided, industry-specific digital experiences and complex business processes. It enables developers to create pixel-perfect user interfaces (for example, guided workflows and dynamic dashboards) using drag-and-drop components like <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_flexcardsbasics_8118.htm&type=5">Flexcards</a> and <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">Omniscripts</a>. With Omnistudio, you can declaratively create LWCs.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Lightning Web Components</strong></td>
<td colspan="1" rowspan="1">Salesforce <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Lightning Web Components</a> are lightweight, custom HTML elements that are built using HTML, CSS, and modern JavaScript, and designed to run natively in browsers for superior Salesforce UI performance. They allow developers to create custom user interfaces that coexist with <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Aura</a> components, which increases development through industry standards and a detailed component ecosystem.</td></tr></table>

### Tool Skillsets and License Requirements

This table outlines the tools that are available for building forms via Salesforce, along with their required skills and license considerations.

**Note:** We’ll dive deeper into the specific features that are supported for each tool, how to choose between click-based tools and code-based tools, and when to combine them in a later section.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Configuration</th>
<th colspan="1" rowspan="1">Additional License Requirements</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Low Code</td>
<td colspan="1" rowspan="1">None</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Low Code</td>
<td colspan="1" rowspan="1">None</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Low Code + Pro Code</td>
<td colspan="1" rowspan="1">Industries Package</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow plus Lightning Web Components</strong></td>
<td colspan="1" rowspan="1">Low Code + Pro Code</td>
<td colspan="1" rowspan="1">None</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Lightning Web Components</strong></td>
<td colspan="1" rowspan="1">Pro Code</td>
<td colspan="1" rowspan="1">None</td></tr></table>

## Decision Points

There are a number of decision points to keep in mind when you’re making product and tool selections. This table outlines various decision points and provides high-level guidance.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Decision Point</th>
<th colspan="1" rowspan="1">Guidance</th></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Runtime Use Case Categories</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Form Scope and Navigation</strong></td>
<td colspan="1" rowspan="1">Determine whether all fields on your form will fit logically onto a single screen, or if users need to be able to navigate between multiple screens.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Location</strong></td>
<td colspan="1" rowspan="1">Identify the location(s) where you want to embed the form, which can range from within a Salesforce app, to a mobile app, to an external website.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Controller</strong></td>
<td colspan="1" rowspan="1">Identify the actions or logic that must be performed behind the scenes while users are interacting with your form, including data transformations and integrations with external systems.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Validation</strong></td>
<td colspan="1" rowspan="1">Determine whether you have any additional input validation requirements that go beyond the standard system-level validation that Salesforce provides.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Interaction Design</strong></td>
<td colspan="1" rowspan="1">Identify the types of interactions or conditions that should trigger dynamic responses within your form.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Styling</strong></td>
<td colspan="1" rowspan="1">Determine the level of sophistication that&rsquo;s necessary for your desired styling and CSS requirements.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Layout</strong></td>
<td colspan="1" rowspan="1">Identify your form&#39;s layout requirements (for example, the required number of columns, tabs, and accordions) and the ability to display repeating blocks of data.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Translation</strong></td>
<td colspan="1" rowspan="1">Determine whether your form must be localized for other languages.</td></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Non-Functional Considerations</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Security</strong></td>
<td colspan="1" rowspan="1">Determine whether your form should check the user&rsquo;s access before performing certain operations, whether you want to control who can access the form, and whether you want to control where the form can be embedded.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Object Impact</strong></td>
<td colspan="1" rowspan="1">Determine whether your form will operate against a single object or against multiple objects.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>UI Test Automation</strong></td>
<td colspan="1" rowspan="1">Determine whether your DevOps processes require your form to undergo automated unit testing or automated end-to-end testing.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Metrics</strong></td>
<td colspan="1" rowspan="1">Identify how you&#39;d like to track your form&#39;s usage, including page views, amount of time spent on the form, completion rates, and success rates.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Packaging and Deployment</strong></td>
<td colspan="1" rowspan="1">Determine how you want to distribute or deploy your form after it&#39;s been built.</td></tr></table>

**Note:** In subsequent decision-comparison tables, there are a handful of values that are associated with any tool-feature pair:

- **Available:** The tool/feature works with basic considerations.

- **Not Available:** There aren’t any plans to add support within the next twelve months.

- **Not Ideal:** This tool/feature may work, but it isn’t the optimal tool.

- **Not Applicable:** The tool does not apply to the particular use case.

## Use Cases

Use these scenarios to compare tooling choices based on scope, UX, and operational needs.

### Form Scope and Navigation

If you can get all of your user inputs from a single-screen form, start with Dynamic Forms. Keep in mind that Dynamic Forms in record pages can use the Path feature to support staged business processes.

#### Questions to Ask

- Do you need a single screen, or will the user need to navigate between multiple screens to complete a task?

- Do you want your users to see a visual depiction of how far along they are in the process when filling out your form? Will your users be required to fill out the information on each screen in a specific order, or should they be able to move back and forth between screens as needed?

If you need more functionality than what Dynamic Forms offers, choosing between Flow, Omnistudio, and LWC depends on a few additional questions:

- Is it OK to display a navigation bar at the bottom of your form? If the Screen Flow and Omniscript navigation experience provides an undesirable UX, lean toward LWC.

- What needs to occur behind the form? If you need the behavior to be configurable by an admin, use a Flow. For complex, multi-object relationships, use _Omniscript_ or _LWC_.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Single Screen</th>
<th colspan="1" rowspan="1">Multi-Screen Form</th>
<th colspan="1" rowspan="1">Progress Indicators</th>
<th colspan="1" rowspan="1">Jump Navigation Between Steps/Screens</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Ideal</td>
<td colspan="1" rowspan="1">Not Ideal</td>
<td colspan="1" rowspan="1">Not Ideal</td></tr></table>

If you choose Flow or Omnistudio, you may also need to build an LWC to achieve the right UX. If you’re already building an LWC to style your form correctly, consider whether [embedding that component in a Flow](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow) is necessary.

**Wizard-style navigation**

On the other hand, if your solution looks like a wizard—where the user navigates between multiple screens—consider Flow or Omnistudio. Flows and Omnistudio feature a built-in navigation model, so you don’t have to build and maintain LWCs that are strung together. The navigation is linear, with forward-moving actions, backward-moving actions, and a mechanism for saving the form for later. You can also build a form with non-linear navigation if it suits your purposes.

Omnistudio offers a key navigational advantage by providing progress indicators from standard navigation that surface steps within the form. The step view automatically displays where a user is on a multi-step form. Unlike Flow, it lets users jump between screens by clicking on various steps throughout the form.

Whether you’re building single-screen or multi-screen forms, it’s important to ensure that your forms are streamlined so that they’re easy for your users to navigate.

### Form Factor

If you’re embedding a form in a standard Lightning record page, any of the tools that we’re comparing will work; however, Dynamic Forms are currently only available on the desktop. If you want to provide an experience that allows users to access forms from other locations, you may need to consider alternate options.

#### Questions to Ask

- Will users need access to the form via desktop, mobile, or both?

- Should users be able to access the form from anywhere in your app via a utility bar?

- Do you want to enable quick actions so that users can fill out your form without having to leave the page they're currently on?

- Does your form need to be available on an external website?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Lightning Record Page</th>
<th colspan="1" rowspan="1">Lightning Home Page or App Page</th>
<th colspan="1" rowspan="1">Aura Experience Cloud Sites</th>
<th colspan="1" rowspan="1">LWR Experience cloud Sites</th>
<th colspan="1" rowspan="1">Embedded Snap-Ins</th>
<th colspan="1" rowspan="1">Utility Bar</th>
<th colspan="1" rowspan="1">Object-Specific Action</th>
<th colspan="1" rowspan="1">Global Action</th>
<th colspan="1" rowspan="1">Salesforce Mobile App*</th>
<th colspan="1" rowspan="1">Field Service Mobile</th>
<th colspan="1" rowspan="1">Mobile SDK</th>
<th colspan="1" rowspan="1">External Sites and Apps</th>
<th colspan="1" rowspan="1">Custom LWC</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available**</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Ideal</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="14" rowspan="1" style="border-right: 1px solid #d8dde6;">*Flows and LWCs are supported in the Salesforce Mobile App, but it doesn&rsquo;t support all of the ways to embed Flows and LWCs (for example, object-specific actions are supported in mobile, but utility bar items are not).<br><br>**The Salesforce Field Service mobile app includes Data Capture &mdash; an offline-first forms solution built on the Flow engine with a dedicated offline runtime, supporting the latest Flow features. The app also includes the legacy Field Service Mobile Flows, which run on an older, custom offline engine, and does not support many of the latest Flow features.</td></tr></table>

Since it requires record context, the Dynamic Forms feature is only supported in Lightning record pages. However, Dynamic Forms isn’t supported in Experience Cloud pages.

You can build Flows that require a record context, or Flows that work globally. In other words, you can embed Flows in a variety of locations. For record-contextual Flows, locations may include: Lightning record pages, Experience Cloud record pages, an object-specific actions, or Actions and Recommendations deployments. For global Flows, locations may include: the utility bar, other Lightning or Experience Builder pages, snap-ins, or external applications. Currently, Flows aren’t supported as global actions, but you can wrap _Flows_ in an _Aura_ component as a workaround.

Omnistudio lets you build composable FlexCards and Omniscripts that you can place _almost_ anywhere that you can place a Flow, but while they’re composable, they aren’t packageable.

LWC offers a high degree of reusability for creating components that can be associated with targets via metadata across Salesforce, Communities, and open-source projects. LWC components can also be embedded within your own website using [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out on External Sites" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

LWC components can also launch Flows with the [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) component.

Omnistudio excels at exposing content to external sites via the OmniOut feature. With Omnistudio and OmniOut, you can compile your Omniscript forms and FlexCard components into standard components, and then run them off-platform in third-party sites or apps.

Currently, none of the form technologies that are covered in this guide are officially supported in Mobile SDK templates. If Mobile SDK is essential to your use case, we recommend building your form natively in your mobile application or building a Visualforce page, while keeping form factor in mind.

### Logic

Dynamic Forms are perfect if you need to use the values in your form to create or update a record. You’ll need to leverage Flow, Omnistudio, or LWC for capabilities outside that scope, including creating decision or iteration layers, or generating Slack posts or emails using the inputs from the form.

#### Questions to Ask

- What actions or logic need to be performed behind the scenes?

- Do you need to use values from a related record?

- Will your form need to complete its operations within a single transaction or across multiple transactions?

- Do you need to integrate with external systems?

- What are your requirements for reusability and modularity?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Log and Actions</th>
<th colspan="1" rowspan="1">Hierarchical Data Management</th>
<th colspan="1" rowspan="1">Operate within One Transaction</th>
<th colspan="1" rowspan="1">Operate Across Multiple Transactions</th>
<th colspan="1" rowspan="1">Integration</th>
<th colspan="1" rowspan="1">Modular Design and Reuse</th>
<th colspan="1" rowspan="1">Packaging</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr></table>

Flow offers standard actions for posting to Slack, sending emails, and interacting with Quip documents, and you don’t have to write code for any of these operations. LWC offers rich interactions with single records and related objects via wire adapters that interact with the [User Interface API](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm). LWC can also interact with multiple records using the wire for [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="LWC Interaction via Wire Adapters" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio uses integration procedures and Data Mapper to obtain and transform data (both external and internal to Salesforce). Due to numerous code-free functions, it excels at flattening and expanding data sets with various levels of relationships.

Flow, Omnistudio, and LWC all integrate with Apex, so you can easily close any gaps within the solution you choose (for example, if you need filtering records from an LWC, you can use the wire adapter for Apex to create complex SOQL queries. If you’re swayed by click-based stories, consider using Flow or Omnistudio as a viable alternative to an Apex controller for your server-side needs.

You should also consider whether you want to immediately commit actions, or defer them to a particular part of your form. This is especially relevant if you’re using a multi-page form. Flow makes it easy to combine inputs from multiple forms (flow screens) and use them later in the wizard (flow) to perform certain operations, which is exactly how we recommend designing Flows. Perform actions at the end (in case users bounce back and forth between screens to change their answers).

#### Control Operations

Transactions and [governor limits](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) are integral to the Agentforce 360 Platform. If your use case is fairly simple, it may not be as important to control the transaction where a particular operation occurs. However, there are a few use cases where you may want to combine multiple operations into a single [transaction](/docs/architect/fundamentals/guide/architecture-basics#transactions) rather than performing them across multiple transactions.

Here are a few examples:

- **Rollback:** Let’s say your form creates multiple records behind the scenes. If creation of a third record fails, should the first two records be rolled back? If each of your actions are independent from one another, you can execute them as separate transactions. However, if they’re dependent upon one another—and you want the failure of one to also rollback the others—you should implement them as a single transaction. If your form is in Flow, you can use the Rollback element in the Fault path to roll back your transaction and ensure data integrity.

- **Downstream Impact on Governor Limits:** When your form creates or updates a record, it’s important to consider what the downstream implications of that operation are:

  - What processes, workflow rules, Flow triggers, Apex triggers, or other items within the save order may fire based on the proposed record changes?

  - How do those collective changes impact the governor limits that are being consumed within that transaction?

  - If a particular record change may result in many downstream changes that impact your limits, it may be best to consider isolating that record change within its own transaction.

- **Batch Processing:** You may need to batch multiple updates together (even within a UI context). Let’s say your multi-screen form iterates over a large group of records. Rather than committing a record update after each screen—wait until you’ve collected the updates for all of the records—and then submit one request to update all the records.

When you use Dynamic Forms to create or edit a record, you’re only performing one operation, and that operation is always the start of a net-new transaction.

When you’re building a screen flow, you have significant control over what occurs within a given transaction. Screens and local actions act as boundaries between transactions. Here’s a high-level summary of how transactions are managed within the screen flow architecture.

1. The end user interacts with a screen, and then clicks **Next**.

2. The client posts an input request to the API.

3. The API receives the request, and opens a transaction and database connection. Then, the API calls the Flow engine to invoke the request.

4. The Flow engine takes over and follows the appropriate path in the flow definition—until it hits a screen or local action node. Then, the engine returns information about that node to the API.

5. The API creates a response object that contains the details of the next screen to render, and returns that object to the client. At this point, database changes are committed (per the [save order execution](/docs/architect/fundamentals/guide/architecture-basics#database-manipulation)), and the database connection and transaction are closed.

6. The client uses the API response to render the next screen that the user interacts with.

7. Start from step 1 and repeat the process.

In other words, screens _break_ transactions. When this occurs, any pending actions or DML are committed, the prior transaction is closed, and a new transaction begins.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="multi-screen flow" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Keep in mind that the specific design elements (which operations you group into a given transaction) are up to you.

Here are a few examples:
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="screen flow with separate transactions" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

- When you begin, you’ll see a flow that collects inputs across multiple screens, and then performs several actions within one transaction.
- The next flow performs each operation in a separate transaction.
- Flows can also use Roll Back Records to enable you to roll back an entire transaction if a single operation fails within a series of database operations.
  <image src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Screen Flow with multiple create records" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
  Let’s say you have a flow that creates records, updates records, and then creates additional records (illustrated in the next flow).

In this scenario, if the first two elements succeed and the last fails, the first two DML operations still create and update the appropriate records, but the third won’t.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Screen Flow with Rollback" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
By using the Roll Back Records element, you can ensure that the entire transaction is rolled back if all three operations must occur collectively (as seen in the final flow).

**Note:** For more details, check out [Flows in Transactions](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) and [Flow Bulkification in Transactions](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm).

Your ability to control the transaction from an LWC is based upon the underlying services that the LWC is using to perform its operations. If you’re using the lightning-record-form base component, the underlying operation (creating or updating the record) occurs within a standalone transaction when the form is submitted.

In general, these rules apply:

- Each UI API call is isolated within its own transaction.

- If you need to perform multiple operations within a single transaction, send the inputs to a server-side technology (for example, an Apex controller or a Flow). Keep in mind that the regular transaction rules for that technology still apply.

#### External Integrations

Flow, Omnistudio, and LWC all support platform events (for [event-driven architecture](/docs/architect/decision-guides/guide/event-driven)) and API integrations. In addition to custom Apex code, Flow and Omnistudio have declarative support mechanisms that can also integrate with APIs.

If you need to connect to a MuleSoft API or RPA bot, use MuleSoft Services, as this generates an External Service.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="External integrations via MuleSoft" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

If the API has an OpenAPI schema, create an External Service.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="External Integrations via OpenAPI" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

For all other instances, use the **HTTP Callout** feature (powered by External Services) in Flow or the **HTTP Action** in Omnistudio.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="External integrations via HTTP" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Omnistudio features a rich set of integration capabilities that can call out to external systems using integration procedures to transform data via Data Mapper.

Regardless of whether you use custom Apex code or an external service for implementation, a **callout** is still a callout.

Here’s what you need to know.

- A callout may take a significant amount of time to process.

- When a callout is executed synchronously, it's performed while a database transaction is open.

- Salesforce doesn't allow you to keep a database transaction open if you have any pending database operations.

Keep in mind that the main limitation is the danger of leaving data in an inconsistent state, which occurs when you perform a **create**, **update**, or **delete** operation, and then execute a **callout** within the same transaction. This pattern isn’t permitted due to the third consideration mentioned above, which exists because of the first two considerations.

In Flow, you can bypass this limitation by breaking the transaction. Remember, screens and local actions reintroduce the browser context. While you can use screens and local actions when you’re working with external callouts, we recommend enabling **Transaction Control** in the invocable advanced settings. Transaction Control allows you to automatically end the transaction before a callout is made. To enable Transaction Control, select “**Always start a new transaction**” in the **Advanced** section of the invoked action.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="External Integrations via Callouts" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
LWC helps simplify the impact of callouts on the transaction. In other words, perform your data operations using the Lightning Data Service (LDS), and then use an Apex controller to make the external callout. Since the LDS call is isolated within its own transaction (separate from the Apex callout), this protects you from resultant data inconsistency.

#### Reusability and Modularity

Dynamic Forms don’t support reuse. Each one is tied to a specific Lightning record page for a specific object; however, you can assign that Lightning record page to multiple apps, profiles, and so on.

Similar to how you can write libraries, utilities, and components that can be used across multiple components, you can also apply similar design patterns when you’re creating flows by harnessing the power of **subflows**. To do so, save your flows in smaller, modular buckets, and then call them from other flows using the **Subflow** element. If your design calls for it, you can build a flow that’s useful on its own and as a subflow.

Omnistudio is inherently built for modularity. Data Mappers, Omniscripts, FlexCards, and Integration Procedures are all built independently, but they can also work interchangeably. FlexCards can also be built as LWC components that are embeddable within other LWCs, Omniscripts, record pages, and Experience Cloud sites.

Screen flows, Omniscripts, and LWCs can all be built for reuse and embedded within a variety of locations, including external sites and Lightning Out applications. When you design your solutions to be composable, you also gain adaptability and stability benefits.

### Validation

All technologies that are used to create or update records must adhere to system-level validation, whether they’re classic validation rules or custom validations that are built into an Apex trigger. No matter what technology you use to perform record changes, every change must go through the save order. This means that in addition to validation rules, record changes are also processed by a number of before- or after-save flows, before- or after-triggers, escalation rules, assignment rules, and so on.

**Note:** If you haven’t already done so, review and bookmark the Apex [order of execution](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm).

#### Questions to Ask

- Does your form have any additional requirements beyond system-level validation?

- Do you need to set required or read-only fields dynamically within the form?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Respect System-Level Validation</th>
<th colspan="1" rowspan="1">Custom Field-Level Validation Specific to this Form</th>
<th colspan="1" rowspan="1">Custom Field-Level Validation</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr></table>

Typically, inputs on a flow screen or Omniscript step are unbound, so the form itself doesn’t natively adhere to the system-level validation that’s associated with a particular object. However, the values that you use to create or update records are processed in the save order, which means that they pass through the object’s system-level validation.

**Note:** Not all Screen Flow components support input validation.

Similar to page layouts, Dynamic Forms let you set the **requiredness** and **read-only** state at the page level. Keep in mind that you can’t override system-level settings.

Flow provides flexibility for customizing form input validation. Multiple checks are performed at the client level (for example, flagging required fields that are missing and data-type checks, as well as compatible formulas within input validation rules). As an added level of security, input validation is also evaluated on the server. When a user clicks **Next**, Flow sends the inputs to the server for validation again. If any invalid inputs are returned, navigation is blocked and the appropriate error is displayed.

The server validates the inputs by checking:

- The input’s **requiredness** setting, or whether the entered value is compatible with the underlying data type.

- The custom validation of the input. You need to supply a _Boolean_ formula expression and an error message to display when the formula expression isn’t met.

- The custom validation of the underlying component. If you’re building a custom LWC for a Flow, you need to add your own validation code to the validate() method.

You can also provide accessible user alerts via the **Message** component in Screen Flows, but this doesn’t prevent a user from navigating to other pages, or progressing to the next step in a guided Flow. The _Error_ state within the **Message** component is best used on dedicated error screens that are triggered via a fault path when navigation is disabled.

Omnistudio features robust error and validation handling via the [Set Error](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) action in combination with [Conditional Views](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) and the [Messaging](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5) component.

For LWC, most of the base components perform their own client-side validations (for example, lightning-record-form respects system-level requiredness, but not page-level requiredness). For your custom components, you can build your own validation mechanisms.

Keep in mind that fields that require users to input data should appear at the beginning of your forms. Validate user inputs on the client side before forms are submitted (when possible).

### Interaction Design

Static forms are outdated. Today, the focus has shifted to dynamically updating forms with the right properties and values for a _specific_ user, at a _specific_ time, in a _specific_ place. Let’s take a closer look at what’s feasible via Salesforce form-building tools.

#### Questions to Ask

- What types of interactions or conditions should trigger dynamic responses within your form?

- Do you need to execute off-screen (background) operations while your form is being filled out?

- Do you need to set fields as **visible**, **required**, **read-only** or **disabled**, or do you need to change formatting based on form inputs?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Execute Off-Screen Data Operations</th>
<th colspan="1" rowspan="1">Conditional Values and Calculations</th>
<th colspan="1" rowspan="1">Conditional Visibility</th>
<th colspan="1" rowspan="1">Conditional Requiredness</th>
<th colspan="1" rowspan="1">Conditional Formatting</th>
<th colspan="1" rowspan="1">Conditional Read-Only State</th>
<th colspan="1" rowspan="1">Conditional Disabled State</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="8" rowspan="1" style="border-right: 1px solid #d8dde6;">*Limited to components that use a resource picker and not a static checkbox</td></tr></table>

**Reactive Screens** enable Screen Flow interactivity. Reactivity allows individual components on a flow screen to communicate with each other, which makes Screen Flows more powerful.

**Execute Off-screen Data Operations**

Screen Flows provide a declarative approach to fetching data on the same screen via **Screen Actions**. Screen Actions allow you to trigger autolaunched flows on any change within the screen, or when a user clicks an **Action Button** component. You can map autolaunched flow results to the same screen, which eliminates the need for users to navigate to another screen.

LWC provides a full array of wire adapters that provide access to Salesforce data to dynamically populate data in form components, which allows developers to **update**, **delete**, and **create** records via Apex controllers.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Lightning Web Components Off-Screen Data Operations" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

**Visibility**

Visibility can be dynamically controlled in all form-building tools. Dynamic Forms, Flow Builder, and Omnistudio address this using component visibility features. You can declaratively **show** or **hide** fields based on other values within the form, or whether the user is completing the form on a mobile device.

- Dynamic Forms control visibility based on record field values, lookup fields, and form factor.

- With Flow, you can base a visibility rule on other screen inputs, as well as other resources that populate earlier in the flow (for example, formulas or values from other records).

  - **Device-Based Rules:** It may not be obvious from the start, but you can use a formula to **show** or **hide** a particular field when the user is on a mobile device. Write a flow formula that checks the value of the **\$User.UIThemeDisplayed** global variable. If the value is **Theme4t**, the user is completing the form using the Salesforce Mobile App.

  - **Evaluate Other Resources:** Manual variable and formula references are only evaluated on the server. This means that the value that resource has when the screen first renders is the value that it will have until you navigate to another screen. During navigation, the flow runtime submits a request to the flow engine (the server), and it returns the latest manual variable and formula values. If you expect your visibility rule to update as the user passes through a single screen (for example, onblur), you need to ensure that you’re only referencing values from the other components on the screen.

- With Omnistudio, you can conditionally **show** or **hide** components by setting up a **Conditional View** property. However, you can’t add more than one Conditional View property for an input.

**Conditional Input States**

If you need to dynamically control any other properties (for example, whether a field is **required**, **disabled**, or **read-only**), there are a few options. LWC provides full, reactive control over your input state. With Reactive Screen Flow components, you can dynamically control component attributes (for example, **read-only**, **disabled**, and **required**) for standard components that support it, while Omnistudio supports the full spectrum of component-specific attributes. If your requirements dictate that you need Flow, and the component doesn’t support a specific attribute state, you can create an embeddable LWC to achieve a dynamic input state.

If you need to dynamically control any other properties (for example, whether a field is **required** or **read-only**), use LWC in the short term since you have full control. This is especially true if you have bespoke requirements for how to handle onblur or onclick.

**Reactive LWCs in Screen Flows**

If you’re building LWCs that can react to and change other components on a Screen Flow, check out the [LWC Best Practices for Screen Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) guide to ensure that your components integrate with the flow runtime engine and function as intended.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Standard Event Handling(onblur, onfocus)</th>
<th colspan="1" rowspan="1">Custom Event Handling</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*The Omnistudio Standard Runtime does not support Pub/Sub, but does support Windows postMessage</td></tr></table>

For custom events, If some of your inputs (or the entire form) need to communicate with another element on the page, LWC is your only option.

- To communicate within the same DOM tree, use the [CustomEvent interface](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events).

- To communicate across the DOM, use the [Lightning Messaging Service](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel).

- If Lightning Messaging Service [isn’t supported](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) for your target container, use the pub/sub module.

#### Additional Resources for Interaction Design

- For more detailed information , check out [Communicate with Events](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) and [Communicate Across the DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) in the _Lightning Web Components Dev Guide_.

- For Omnistudio, check out [Communicate with Omniscript from a Lightning Web Component.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)

### Styling

To provide the best user experience, it’s important to ensure that your form styling is consistent with the rest of the app or site where it’s being embedded. This may mean using standard templates that are provided by Salesforce, or creating a custom CSS that uses every pixel in the design to provide a sharper look and feel.

#### Screen Flow Styling Overrides

Admins can configure a limited set of Screen and Component Styling Overrides (for example, colors, borders, and button appearances), for the screen container or for individual components. These overrides are applied after themes and branding, which allows builders to make targeted visual adjustments without impacting the rest of the application.

Styling overrides are intended for localized visual exceptions (for example, highlighting a confirmation screen or emphasizing a specific call-to-action (CTA); they aren’t a full styling system. They don’t provide CSS-level control, and they aren’t designed to be reused across screens or flows.

From an architectural perspective, styling should follow this precedential order:

1. **Themes and branding:** Lightning Themes, Experience Builder Branding Sets, or LWR site theming

2. **Flow styling overrides:** Targeted screen or component adjustments

3. **Custom components (LWC):** when pixel-perfect control or reusable design patterns are required

Using themes and design systems helps to ensure that styling remains consistent, scalable, and easy to maintain over time.

#### Questions to Ask

- How sophisticated is your desired styling and CSS?

- Do you need custom, pixel-perfect styling or standard themes?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Direct Styling</th>
<th colspan="1" rowspan="1">Org and Experience Builder Themes</th>
<th colspan="1" rowspan="1">Pixel-Perfect Styling</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">*FlexCards only<br><br>**Certain style attributes can be configured for screen components, but not CSS overrides.</td></tr></table>

FlexCards is the only product in this guide that enables you to declaratively control the styling and layout of the UI you’re building within the tool (for example, margins and padding, typography, colors, and so on).

Dynamic Forms and Flows respect declarative theming features. If you need additional control (beyond what [Salesforce Themes](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [Experience Builder Branding Sets](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm), or [LWR Experience Cloud Sites](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm) support), consider a programmatic solution.

Teams that are comfortable working with CSS have several options:

- Flows and LWCs inherit [standard design tokens](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm).

- Omniscripts and FlexCards include customizable design system support via [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5).

- With LWC, you can write your own components and fully control their HTML and CSS.

When possible, we recommend using themes and design systems to ensure a consistent look-and-feel across all of your content.

**Note:** You can embed Lightning components in Flows. If you need pixel-perfect control over the look-and-feel of your form, but you also want to use the other benefits of Flows (for example, the navigation model), you can have the best of both worlds\! The same principle applies to Omniscripts and FlexCards.

### Layout

Choosing a good layout is crucial to designing streamlined forms that enable fast and efficient data entry and increase data integrity.

#### Questions to Ask

- How can you structure form layouts to optimize user experiences?

- How can you present existing data to users in a way that makes it easier for them to enter new data into your forms?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">2 Columns</th>
<th colspan="1" rowspan="1">4 Columns</th>
<th colspan="1" rowspan="1">Beyond 4 Columns</th>
<th colspan="1" rowspan="1">Repeating Blocks of Data</th>
<th colspan="1" rowspan="1">Tab Containers</th>
<th colspan="1" rowspan="1">Accordion Containers</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="7" rowspan="1" style="border-right: 1px solid #d8dde6;">*Tabs can be used if embedding data in a FlexCard in an Omniscript</td></tr></table>

Dynamic Forms support two-column layouts that can be broken into individual sections within fields. These sections can be placed within components (for example, tabs and accordions) to create organized, easy-to-use layouts.

Flows can also be rendered using the **Section** component. You can add up to four columns and an unlimited number of sections on the flow screen. The sections component is also responsive to screen width, so it also works on smaller screens. It gives you the ability to apply conditional visibility to the entire section, which makes it easier to mass-apply visibility to multiple fields within the section. **Flow Sections** also support column headers and give an accordion-like experience where users can collapse the entire section by clicking on the label.

Omniscripts feature a variety of layout options for displaying fields and data. You can create sections of data with up to 12 columns, including conditionally-collapsible accordions.

With LWC, you can use lightning-record-\[edit|view\]-form and the supporting lightning-\[input|output\]-field to control the layout. The only layout restrictions come from HTML and CSS. The **lightning-record-form** component respects the section configuration in the associated page layout (for example, if a section is two-column in the page layout, it’s also two-column in the component).

### Translation

If your form needs to be accessible by users in different regions or who speak different languages, you need to ensure that the tool you’re using to build it meets your localization requirements.

**Note:** For forms specifically, localization requirements typically involve translating text elements into other languages.

#### Questions to Ask

- Is your form going to be used in more than one country or region?

- Does the text in your form need to be localized to other languages?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Labels Entered in the Builder</th>
<th colspan="1" rowspan="1">Labels in the Code</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Not Applicable</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Field Section Headings only</td></tr></table>

If you localize custom fields, Dynamic Forms respects the translated labels. Dynamic Forms also respect any [custom labels that are assigned to component labels and attributes](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) in Lightning App Builder.

Flow supports the translation of user-facing labels for all standard and custom screen components via Translation Workbench.

You can localize labels, help text, and error messages on these screen components:

- Text
- Long Text Area
- Number
- Currency
- Checkbox
- Radio Buttons
- Picklist
- Multi-Select Picklist
- Checkbox Group Password
- Date
- Date/Time

There is no built-in translation support for out-of-the-box actions (for example, Send Email or Post to Chatter), but there is a workaround. If you use a [custom label](https://help.salesforce.com/articleView?id=cl_about.htm) to define the translated labels, you can reference that custom label in the action or component when you configure it in Flow Builder. To do so, you need to create a flow formula that references the custom label, and then reference that formula in the appropriate places within your flow.

Omniscripts make use of custom labels for translations. For more information, check out [this help doc](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm) to ensure that your Omniscripts are multi-language ready.

For LWC, certain base components automatically inherit translations of the associated object’s fields, help text, and validation messages if they’re configured in Translation Workbench (for example, lightning-record-form).

If you need to introduce novel translatable labels in your code, custom labels are the way to go. Declare the custom label that you need, and then import it into your component from the `@salesforce/label` scoped module.

## Non-Functional Considerations

Use this section to evaluate security, quality, and operational constraints before implementation.

### Security

Security is a complex topic, and when it comes to building forms, there are a number of considerations that may not be obvious. At the foundational level, you need to ensure that the form is running in the correct context, and that users have the permissions they need to work with its underlying data. Beyond this, you may also want to take extra measures to strip out potentially malicious code or URLs from rich-text fields, prevent certain users from accessing the form, or place limitations on the types of locations where admins can potentially embed the form in the future.

Be sure to document your security requirements thoroughly before choosing a tool. For additional guidance on this type of documentation, check out the Salesforce [Well-Architected Security Policy Template](/docs/architect/resources/guide/security-policy-template).

#### Questions to Ask

- Should the form check the user’s access before performing certain operations?

- Should you sanitize user inputs?

- Do you want to control who can access the form?

- Do you want to control where the form can be embedded?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Elevate User Permissions</th>
<th colspan="1" rowspan="1">Control Who Has Access</th>
<th colspan="1" rowspan="1">Restrict Allowed Locations</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">*Requires Apex<br><br>**While Omniscripts cannot have a specified set of target locations, FlexCards can.</td></tr></table>

#### Elevate User Permissions

When a program runs in **user context**, Salesforce enforces a series of access checks, which include verifying field-level security, CRUD permissions, and record access based on your organization’s sharing rules (for example, users would only be able to run a case update form if they have the ability to update cases, the appropriate field-level security, and access to the record in question).

What happens if you want users to be able to perform a particular operation when they're using your form, but not via any other form or interaction? That’s where **System Context** comes in\!

**System Context** allows you to elevate a user’s permissions for the duration of the session (for example, the user doesn’t need to update access to the Case object to successfully complete your case update form). This is especially useful for unauthenticated communities. Rather than granting guest users potentially dangerous abilities, set your form to run in system context.

System Context should only be used when it’s absolutely necessary. When a form runs in System Context, every CRUD operation bypasses the object- and field-level security and sharing components. Also, System Context has no bearing on who Salesforce considers to be the _actor_ (the name you see in the **Last Modified By** field). For each operation that your form performs (for example, a case update), the _actor_ is the current user (even if the form runs in a different context).

**Note:** Dynamic Forms, Omniscripts, and LWCs always run in user context, and there’s no way to override this behavior.

Screen Flows run in user context by default, but you can set them to run in system context. You can decide whether the flow should grant access to all data, or if it should enforce record-level access.

- If you embed a Lightning component within a flow that runs in system context, the flow won’t override the component’s context. If you need to bypass user-access checks, use the flow to perform those operations and pass the appropriate data into or out of the Lightning component. Some out-of-the-box components (for example, Lookup) can’t operate within system context.

- If your flow calls Apex actions, other nuances are involved.

  - If the Apex class is set to _inherited sharing_, then it will run in system context with sharing no matter how the flow is set.

  - If the class has no explicit sharing declaration, then it will run in system context without sharing no matter how the flow is set.

  - If the class is set to _with sharing or without sharing_, it will override the flow's context.

**Query Records in System Context with Experience Cloud Sites**

If you’re running a Flow in System Context on an Experience Cloud site (especially if it’s unauthenticated), store only specific fields in your **Get Records** elements. When you're working with Flow and you pass the results of a **Get Records** element into a Subflow, invocable action, or a Lightning component, all of the fields from that object may be inspected by the browser’s developer tools. Despite your intentions, this may make fields available to Experience Cloud users. To ensure that only the correct fields are exposed when System Context is enabled, specify those specific fields in your **Get Records** elements.

**Note:** Omniscript logic runs on the client side, which makes it possible for attackers to modify the expected execution of an Omniscript and view responses to Integration Procedures, Data Mappers, and Apex method calls via the browser's developer tools. When you're using Omniscript, it’s important to execute business logic on the server side (when possible), and implement input validation rules for any Apex methods that are exposed via an [@InvocableMethod annotation](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5).

**Sanitize Inputs**

To protect your organization from bad actors, use input sanitization. Let’s say you have an input on a publicly accessible form that can be mapped to a **Rich Text** field within your organization. You may want to consider enabling automation that strips out any HTML that may hide malicious URLs.

It isn’t ideal to implement sanitization at the form level because you may have any number of sources that write to these fields. To help combat this issue, create a **Fast Field Update Flow (Before Save),** or use an existing **Apex Trigger** to strip out or modify any potential HTML that may be entered within the form.

#### Best Practices

- Allow Flows to run in their default context (unless you need to elevate the current user’s access for a specific operation).

- Avoid running Flows in System Context for guest users. Create permission sets with limited field access and assign them to the Experience Cloud guest user’s profile.

- When querying records in System Context Run Flows on Experience Cloud sites, only store the fields that you need in the **Get Records** element or **Invocable Actions**.

- If a Flow performs a variety of operations—all of which don’t require elevated access—use Subflows to isolate the operations that should run within System Context.

- If you’re embedding a form within an external webpage, it may need to be mapped to **Rich Text** fields to help prevent potential phishing attacks. To do so,, sanitize user inputs to remove HTML using a **Fast Field Update Flow** or **Apex Trigger**.

#### Additional Notes

- Omniscripts, FlexCards, and LWCs run in user context by default.

- LWCs run in user context by default.

- Flows run in user context, but you can override it by using an Apex controller.

- Operations that are performed within the UI API are run in user context.

- Operations that are performed with an Apex controller depend on the specific class. To perform these operations in system mode, set the **Apex class** to with sharing or without sharing.

#### Access Control

If you need to control who can access a form, review the container where the form is embedded (for example, you can assign Lightning pages to be available for particular apps, record types, or profiles). If certain inputs are sensitive, use visibility rules to further control what’s displayed to whom. This feature applies to Dynamic Forms and Screen Flows.

You can [restrict a Flow](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) to particular profiles or permission sets (similar to Apex class or Visualforce pages). Flows are unrestricted by default, which means that any user with the **Run Flows** user permission is able to access them.

If you're using Omnistudio, you can configure an [Apex class permissions checker](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) that requires users to have explicit access to the Apex class that administers remote actions from Omniscript, Flexcard, Classic Card, or REST APIs.

**Note:** Apex class permission checks only apply to Apex classes. It’s also advisable to set profile-level permissions for [Integration Procedures and Data Mappers](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5).

#### Access Control Best Practices

- If you’re exposing a Flow to guest users, you should only grant guest user profile access to the Flows that they absolutely need. It’s possible to add **Run Flows** to guest user profiles; however, this practice can be risky.

- Use caution when working with Flows that operate in System Context. You should restrict these Flows to a particular set of users since they have fewer checks and balances in place to protect your data.

- Ensure that any Omniscript that runs Apex within a guest user community has **with sharing** listed in the Apex class definition.

- For guest user profiles, only assign the Apex classes that you want to allow guest users to call. By following this practice, it helps to prevent unintentionally exposing additional business logic to guest users.

For LWCs, you can check the current user’s permission assignments to confirm whether they have a particular standard or custom permission. You can import Salesforce permissions from the `@salesforce/userPermission` and `@salesforce/customPermission` scoped modules directly in **JavaScript**. You can also use Apex to check permissions.

#### Embed Controls

LWCs are only available in a given location after they’ve been added as a valid [target](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) (for example, you can make a component available on record pages and unavailable as a utility bar item).

Once a Screen Flow is activated, it’s available in all of the locations that Screen Flows are supported. Flow Builder supports multiple types of Flows that have screens. The most prominent type is **Screen Flow**, but there are a few other specialized types that are restricted to specific locations (for example, the **Field Service Mobile App** only supports **Field Service Mobile Flows)**. This is similar to **Contact Request Flows**, which are only supported in Experience Cloud.

Regardless of the Flow type, the person creating the Flow has no control over where the Flow is embedded. Flows are available in every location where that specific flow type is supported.

If you’re using Salesforce Industries, there’s a slight caveat when it comes to Omniscript.You can’t specify a target for an Omniscript; however, you can specify a target for the FlexCards that you want to embed.

### UI Test Automation

At Salesforce, there are several end-to-end test automation tools (for example, check out [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)) that allow you to simulate how a user interacts with your forms. You can write tests for any standard or custom UI, including Lightning pages and Screen Flows.

**Note:** These types of tests can't verify the outputs for the methods that are being performed. Keep this in mind when you’re configuring your UI test automation requirements.

#### Questions to Ask

- Do you need automated testing for your forms?

- What types of tests do you plan to perform?

- What level of granularity is necessary for test automations?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Unit Tests</th>
<th colspan="1" rowspan="1">End-to-End Automation</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Available*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Requires Code</td></tr></table>

**Consider UI Test Automation Requirements**

**Unit tests** provide granular automation and validation that aligns with industry standard CI/CD systems and tools, which test the business logic, JavaScript controls, and outputs of specific components. If you choose a low-code approach, you won’t be able to self-author tests; however, Salesforce rigorously tests all end-to-end offerings.

If your component’s methods are complex, you can text them individually by placing the methods into dedicated JavaScript files. This allows you to import them into an LWC, and then into a **Jest test (for example,** import { sort } from 'c/utils';).

You can use a no-code solution from an ISV, build a custom test-automation solution, or use an open-source test framework (for example, Selenium WebDriver or WebdriverIO) for end-to-end automation. These solutions are valid for all Salesforce UI interactions (for example, a Dynamic Form in a Lightning page, a Screen Flow in a utility bar, or an LWC in a quick-action Flow).

### Metrics

After you deploy your form to a production environment, you need to ensure that it’s being used effectively. Depending on your use case, this may mean tracking the number of times your form has been filled out to the amount of time the average user spends completing the form before submitting their information. It’s important to identify your trackable KPIs prior to choosing a tool.

#### Questions to Ask

- Do you need to track form usage?

- Which KPIs can determine whether the form is being used effectively?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Page Views</th>
<th colspan="1" rowspan="1">Time Spent on Form</th>
<th colspan="1" rowspan="1">Track Form Completion</th>
<th colspan="1" rowspan="1">Track Success Rate</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available**</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available**</td>
<td colspan="1" rowspan="1">Available*</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="5" rowspan="1" style="border-right: 1px solid #d8dde6;">*Available when Package-Based Omnistudio Runtime is enabled** Available by tracking parent Lightning page usage</td></tr></table>

If you need to track the overall form usage and adoption, use low-code tools. Dynamic Forms and Screen Flows are trackable via out-of-the-box custom reports. However, Screen Flow tracking reports provide additional granularity. If you need to track LWC usage, the out-of-the-box availability depends on where you’re using the LWC. If it’s on a Lightning page, all of the available Lightning page usage tracking elements also apply to your LWC. This is also true for LWCs that are embedded in Flows.

Dynamic Forms aren’t trackable out-of-the-box; however, you can track the usage of the parent Lightning page via [Lightning usage objects](https://help.salesforce.com/articleView?id=lex_usage_reports.htm). To track standard Lightning pages, use the **Users with Lightning Usage by Page Metrics** custom report. For custom Lightning pages, use the **Users with Lightning Usage by FlexiPage Metrics** custom report.

Flows can help you track adoption for specific forms. Use the **Sample Flow Report: Screen Flows** to answer these types of questions:

- What’s the completion rate for this form? Is it currently well-adopted?

- How long does it take users to complete this form?

- Which screen do users spend the most time completing?

- How often do users navigate to previous screens?

- How often do errors occur?

If the standard report doesn’t meet your needs, you can clone it and make changes or build your own report from scratch using the **Screen Flows** report.

If you’re using the package-based Omniscript runtime, you can also use the [Omnistudio for Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). This service tracks all types of events (for example, you can track the time that it takes to complete the steps in an Omniscript, which helps to identify process improvements).

**Note:** There isn’t an out-of-the-box option to track an LWC that isn’t embedded in a Screen Flow, Omniscript, or Lightning page, but you can build a custom solution using Apex.

### Packaging and Deployment

You may be familiar with using change sets or the **DevOps Center** to deploy your solution to testing environments or to production. These deployment options fully support Dynamic Forms, Flows, and LWCs. However, Omnistudio requires a separate tool, the [IDX Workbench](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5).

#### Questions to Ask

- How do you plan to deploy the form?

- Does the form need to be distributed to more than one Salesforce Org?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">First Generation Managed Packages (1GP)</th>
<th colspan="1" rowspan="1">Second Generation Managed Packages (2GP)</th>
<th colspan="1" rowspan="1">Unlocked Packages</th>
<th colspan="1" rowspan="1">Change Sets</th>
<th colspan="1" rowspan="1">DevOps Center</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available</td>
<td colspan="1" rowspan="1">Not Available*</td>
<td colspan="1" rowspan="1">Not Available*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow + LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td>
<td colspan="1" rowspan="1">Available</td></tr>
<tr><td colspan="6" rowspan="1" style="border-right: 1px solid #d8dde6;">*Use IDX Workbench to deploy Omnistudio Solutions to other orgs.</td></tr></table>

If you’re an ISV or a partner who plans to package your solution for distribution on AppExchange, check out Dynamic Forms, Flows, and LWCs. Keep in mind that Omnistudio doesn’t support packaging.

### Navigate the Low-Code to Pro-Code Continuum

This guide is meant to show you what functionality and customization levels are available via Dynamic Forms, screen flows, Omnistudio, and LWC.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Low-Code to Pro-Code Continuum" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Here’s a high-level overview.

- When it comes to building forms, LWC is the most robust, customizable option, but it has the fewest guardrails in place. That’s why it’s crucial to build your components with [security](/docs/architect/well-architected/guide/trust.html) and [scalability](/docs/architect/well-architected/guide/reliability.html#scalability-and-capacity-planning) in mind.

- Dynamic Forms is the least flexible option, but it has far fewer opportunities for missteps.

- Flow and Omnistudio fall slightly in the middle. They’re more powerful than Dynamic Forms, but they aren’t quite up to the LWC level. However, they have fewer guardrails than Dynamic Forms, and they’re harder to break than custom code.

You may find that multiple tools fit your needs. If so, the decision ultimately depends on which tool is best for your team. For more information on additional aspects to consider, check out these [Architect Decision Guides](/docs/architect/decision-guides).

#### Questions to Ask

- When you’re comparing tools, it’s important to assess how much expertise your team has with regard to each tool?
- How many of your developers are well-versed in LWC or JavaScript?
- Are there any developers on your team that are experts in Flow Builder, or who have expressed an interest in learning more?

While we won’t go into specific details, here’s a bit more information on how these specific tools relate to the assessments we’ve covered so far.

**Delivery Delegation**

Keep in mind that even if some of your requirements call for LWC, it doesn’t require the entire solution to be built using LWC. It’s important to determine how you can build your solution modularly. To do so, you need to identify which parts require coded LWC, and which parts don’t. The parts that don’t require LWC should be built using a low-code solution.

When it comes to Flow and LWC, there are various components (for example, Reactive Screen Components and Screen Flow) that can sync with one another on the same screen to unlock new tools for architects, admins, and developers. Developers can now create purposeful, modular components that can be reused across the organization, which helps boost team productivity. This allows developers to save time by using a mix of standard and custom Flow components to achieve form dynamism, which gives them more time to focus on solving new challenges. With the introduction of Reactive Components in Flow, there has never been a more appropriate time to mix Flow and LWC when building forms.

**Long-Term Ownership and Maintainability**

If you’re creating a multi-step form, start with Flow or a mix of Flow and LWC. If the team that’s maintaining the form is a low-code team, ensure that the solution is as configurable and extendable as possible for your intended audience. To improve stability and maintainability, it’s important to organize your solution into [composable](/docs/architect/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity) units, no matter which tool you choose.

### Performance

Performance considerations that relate to Dynamic Forms, Screen Flows, Omnistudio, or LWC are based upon the framework where the technologies are housed. Technologies that are based on LWC tend to outperform those that are based on Aura. Due to several core features that are implemented natively in web engines (rather than in JavaScript via framework abstractions), the LWC provides enhanced performance benefits.

So, how do we harness these performance benefits for our form technologies at Salesforce? Let’s take a closer look.

- Dynamic Forms (integrated within Lightning page metadata) is built upon an LWC-stack foundation, which enables us to implement several long-awaited features. As an added performance bonus, Dynamic Forms uses progressive rendering, which improves load time for pages that have a large number of fields.

- Screen Flows are built upon LWC. Most of the individual out-of-the-box components have now been converted to LWC with the exception of the **File Upload** and **Image** components. While the Flow team has converted the flow runtime client to LWC (and most of its components), customers still need to convert their Aura screen components to LWC. Keep in mind that Salesforce only supports LWC components within the **Reactive Component** framework in Screen Flows. For more information, check out the [Lightning Web Components for Aura Developer](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) Trailhead module. If you’re contemplating building a custom component for a Screen Flow (or any other container), choose LWC\!

- There are several versions of Omnistudio that are available. If you're a long-standing customer, you may be using **Angular**. We encourage all new customers to use LWC-based Omniscripts and FlexCards. We also encourage existing customers to migrate off of Angular.

- LWC is built upon LWC.

## Resources

<table><tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Dynamic Forms</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_overview.htm&language=en_US&type=5">Break Up Your Record Details with Dynamic Forms</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Get Help for Lightning App Builder</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Screen Flow</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">Use Screen Flows to Interact with Users</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Automate Tasks with Flows</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_omnistudio.htm&release=236&type=5">Omnistudio</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">Omniscripts</a><br>- <a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5">IDX Workbench Desktop Application</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Newport Design System</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Customize Omniscripts and Flexcards with the Newport Design System</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">- <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Lightning Web Components</a><br>- <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Lightning Aura Components Developer Guide</a><br>- <a href="https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers">Lightning Web Components for Aura Developers</a></td></tr></table>

<!-- document id=4a0891322eaf4c9dd355ad26436d0d426643af97706aed1e49a2508da73cf6d0 url=/architect/next/en-us/decision-guides/guides/data-360-interoperability.md -->

# Data 360 Interoperability

Enterprises often store data in Salesforce and other external data lakes (for example, _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_, or object storage like _Amazon S3_). Siloing data across multiple systems creates a challenge for companies that want to harness the full value of their data to power AI-driven experiences. Salesforce _Data 360_ is the foundational intelligence layer that every Agentforce AI Agent uses to access the correct context at the correct moment.

Architects who work to bring data together across multiple data lakes face key architectural decisions regarding how best to integrate that data. _Data 360_ provides multiple options for data integration, each offering various pros and cons.

## Guide Overview

This guide provides a framework to evaluate which pattern best fits your requirements for latency, cost, scalability, governance, and complexity when integrating data, helping you choose when to use data ingestion, Zero Copy data federation, or a hybrid approach. The guide will also help you select between different methods of data ingestion and data federation, each of which fills a different need.

Integrating external data-lake houses with _Data 360_ requires carefully considering the trade-offs between data freshness, governance, and pipeline efficiency. For example, using Zero Copy data federation live queries maximizes the freshness of the data but may reduce pipeline efficiency as more data moves over the network. For most real-world implementations, combining ingestion and federation in a multi-cloud lake house ecosystem is the optimal path. This hybrid approach ensures a scalable, governed, interoperable architecture that supports low-latency operational workloads (for example, real-time personalization and fraud detection) and analytical workloads (for example, regulatory reporting and historical trend analysis). This guide helps you determine how to navigate these trade-offs using an appropriate strategy.

## Key Takeaways

- **Data Ingestion** copies data into Salesforce _Data 360_ and creates governed, canonical Data Models. This is ideal for when you need to\:
  - **Build a comprehensive Customer 360\.** This allows you to unify and transform disparate sources into a single, trusted profile.
  - **Meet strict regulatory compliance.** This allows you to create an auditable, centralized copy so that data access and lineage can be closely controlled.
- **Zero Copy Federation** queries external sources in real time without duplication, enabling real-time personalization, live dashboards, and rapid source onboarding. This approach provides two primary options, but there are trade-offs that need to be balanced\:
  - **Live Query\:** Use this for interactive analysis and real-time data dashboards that live in external data platforms (for example, _Snowflake_, _BigQuery_, _Redshift_, or _Databricks_). This helps to avoid slow, costly data duplication by pushing query processing to the source system and returning only necessary results. This approach is optimized for infrequent or ad-hoc queries where freshness is critical. It's suitable for low _query-per-second (QPS)_ workloads (query costs may spike significantly at high QPS).
  - **Caching (Accelerated Query)\:** Use this for frequent data queries that don't change often. Accelerated queries maintain a local cache that's updated at configurable intervals (15 minutes to 7 days), which reduces repeated source hits. This approach balances dashboard performance and cost, segmentation, and BI workloads where slightly stale results are acceptable. This isn't suitable for sub-second decision making.
  - **File Federation\:** Use this for large-scale batch processing and AI model training for data in your cloud's data lake (for example, _S3_ or _ADLS_). This approach avoids slow, costly ingestion by directly querying files in open table formats, which unlocks massive ETL datasets and data science workloads.
- **Hybrid Models** blend ingestion for _Unified Profiles_ with federation for freshness, which supports omni-channel engagement, Agentforce-driven actions, and AI/ML training.

### Important Considerations

- **Employ a Hybrid Architecture.** Mixing data ingestion and federation is often necessary.
  - Use _Data Ingest_ on critical data for canonical data models and core governance.
  - Use _Zero Copy_ for all other data federation to maintain freshness and minimize the operational overhead of building and maintaining data ingestion pipelines.
- **Data Ingestion Frequency Matters.** Choose the frequency based on business value, latency needs, and operational complexity.
  - Use _real-time_ for time-sensitive workflows (for example, personalization, live dashboards, and Agentforce actions).
  - Use _Near real-time_ for moderately urgent processes (for example, campaigns and operational reports).
  - Use batching for historical or low-velocity datasets.
- **Match Federation Patterns to Latency and Performance.** Choose the option that best matches your access patterns and requirements for freshness, performance, and cost.
  - Use _Live Query_ for operational dashboards and real-time personalization where low latency is critical.
  - Use _Caching (Accelerated Query)_ when queries are frequent and slightly-stale results are acceptable, which helps balance performance and cost.
  - Use _File Federation_ for large-scale, throughput-heavy analytics or batch workloads, which are ideal for historical or less time-sensitive datasets.
- **Align Governance with Data Residency Requirements.**
  - Use _ingestion_ when centralized governance is critical.
  - Use _federation_ when decentralized governance is acceptable, while also enforcing strict governance at the external source.
  - Use _Zero Copy_ with respect to source-level policies (for example, _row-level security (RLS)_ and data masking).
- **Prioritize Ingestion for High-Value Workflows.** Apply ingestion selectively to critical processes (for example, identity resolution, regulatory reporting, and operational activation).
- **Cost and Complexity Drive Decisions.** Real-time ingestion can be expensive and complex. That's why it's important for architects to weigh the cost of onboarding, storing, and transforming data against the cost of querying it directly via _Zero Copy_.

Choosing the correct integration pattern—_Data Ingestion_, _Zero Copy_, or a _Hybrid_ approach—directly impacts latency, governance, operational efficiency, and cost across multi-cloud platforms. This decision shapes how real-time insights, AI-driven activation, and personalized engagement are delivered reliably and at scale.

## Product Comparison

This table compares the _Data Ingestion_ and _Zero Copy_ patterns in Salesforce _Data 360_, focusing on capabilities, trade-offs, and benefits, as well as enterprise use cases and outcomes. Use this as a reference for designing hybrid, multi-cloud data platforms that balance performance, cost, and compliance.

<table>
  <thead>
    <tr>
      <th align="left" valign="top"><strong>Pattern Type</strong></th>
      <th align="left" valign="top"><strong>Mode/Tool</strong></th>
      <th align="left" valign="top"><strong>Benefits</strong></th>
      <th align="left" valign="top"><strong>Considerations</strong></th>
      <th align="left" valign="top"><strong>Outcomes</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>Data Ingestion</strong></td>
      <td align="left" valign="top">
        <strong>Real-Time:</strong>
        <ul>
          <li>Sub-second latency ingestion via Ingestion APIs with CDC support.</li>
          <li>Continuous streaming pipelines.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Provides immediate insights</li>
          <li>Embraces low-latency operational and personalization use cases</li>
          <li>Supports event-driven workflows</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>High cost</li>
          <li>Complex architecture</li>
          <li>Low-latency source system requirements</li>
          <li>High-volume sources may cause excessive streaming, which leads to saturated pipelines</li>
          <li>I/O intensive</li>
          <li>Selective fields and filtering may help reduce overhead</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Real-time fraud alerts, retail personalization, and operational alerts</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Sub-second dashboards and KPI monitoring</li>
        </ul>
        <strong>Compliance:</strong>
        <ul>
          <li>Continuous customer record updates for regulated workflows</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Streaming:</strong>
        <ul>
          <li>Micro-batch ingestion every 1–3 minutes via native connectors</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Balances cost vs freshness</li>
          <li>Features a simpler architecture than real-time</li>
          <li>Supports incremental updates</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Slight latency</li>
          <li>May not be suitable for critical sub-second decisions</li>
          <li>Batch size impacts memory/compute</li>
          <li>Moderate I/O</li>
          <li>Suitable for predictable, repetitive update patterns</li>
          <li>Windowed aggregation may help reduce processing load</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Timely campaign triggers and near-live engagement</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Recommendation engines and near-live dashboards</li>
        </ul>
        <strong>Compliance:</strong>
        <ul>
          <li>Frequent updates with auditability</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Batch:</strong>
        <ul>
          <li>Provides scheduled large-volume loads via connectors or APIs.</li>
          <li>Supports object storage and ETL/ELT pipelines.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Supports cost-efficiency for massive datasets</li>
          <li>Features easy implementation</li>
          <li>Provides reliability for historical analytics</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Data latency</li>
          <li>Unsuitable for time-sensitive operations</li>
          <li>I/O intensive during load windows</li>
          <li>Network throughput may become a bottleneck for large files</li>
          <li>Suitable for historical aggregation or regulated reporting workflows</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>IT support tickets (Jira/ServiceNow) and aggregated workflows</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Historical analysis and trend evaluation</li>
        </ul>
        <strong>Compliance:</strong>
        <ul>
          <li>Regulatory reporting and patient/claims data aggregation</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Zero Copy</strong></td>
      <td align="left" valign="top">
        <strong>Live Query:</strong>
        <ul>
          <li>Provides direct queries on external systems and schema-on-read without data duplication</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Provides maximum freshness</li>
          <li>Features minimal storage overhead</li>
          <li>Supports real-time operational insights</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Dependent upon source performance</li>
          <li>High query volume may affect latency</li>
          <li>Suitable for queries with predicate pushdown and aggregation to minimize I/O</li>
          <li>Avoid using unfiltered queries on massive datasets</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Dynamic workflows that adapt to live activity</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Operational dashboards and live reporting</li>
        </ul>
        <strong>Compliance:</strong>
        <ul>
          <li>Respects row-level security and masking at the source</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Accelerated Query (Caching):</strong>
        <ul>
          <li>Provides cached local copies for federated queries that are configurable from 15 min to 7 days.</li>
          <li>Provides optimized query execution</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Reduces latency</li>
          <li>Features lower costs than repetitive live queries</li>
          <li>Improves performance for frequent access patterns</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Cache management required</li>
          <li>Staleness depends on cache intervals</li>
          <li>Suitable for high-frequency queries</li>
          <li>Not suitable for sub-second decisioning</li>
          <li>Incremental refresh supports upserts only; deleted records aren't removed from the cache.</li>
          <li>Periodically requires a manual full refresh to keep the cache in sync with the source</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Pre-aggregated engagement metrics for fast decisioning</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>BI dashboards, segmentation, and analytical reporting</li>
        </ul>
        <strong>Compliance:</strong>
        <ul>
          <li>Consistently regulated dashboards with audit logs</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>File Federation:</strong>
        <ul>
          <li>Provides direct access to large, historical datasets in object stores or lakes (for example, <em>S3</em>, <em>Iceberg</em>, <em>Google BigQuery</em>, and <em>Redshift</em>).</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Processes massive-scale datasets</li>
          <li>Requires minimal storage in <em>Data 360</em></li>
          <li>Supports AI/ML workloads</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Read-only</li>
          <li>Query performance depends on external system throughput</li>
          <li>Suitable for batch-heavy, throughput-intensive jobs</li>
          <li>Not suitable for real-time dashboards</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Not typical (batch-heavy)</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>ML/AI training, historical analytics, and petabyte-scale reporting</li>
        </ul>
        <strong>Compliance:</strong>
        <ul>
          <li>Governs access to external datasets without duplication</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Data 360 Integration Patterns

There are three primary integration patterns for Data 360 - data ingestion, zero copy data federation, and a hybrid approach.

### Data Ingestion

With _Data Ingestion_, data is physically copied into _Data 360_ and fully governed, unlike _Zero Copy_ where data remains at the source. In other words, the computing for transformations occurs within _Data 360_, which provides centralized governance and auditing.

#### Data Ingestion Use Cases

Use _Data Ingestion_ to store canonical, governed datasets in Salesforce _Data 360_ for compliance and operational control. Use ingestion when full control, auditing, and traceability are required. Data Ingestion is ideal for regulated or high-value workflows where centralized compute and governance are critical.

Ingestion is suitable for building a trusted foundation for identity resolution, regulatory reporting, and mission-critical AI-driven workflows and customer engagement.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="Data Ingestion Overview" />

#### Data Ingestion Methods

_Data Ingestion_ methods may vary, depending upon which connector you use to ingest your data. Some connectors offer a variety of ingestion methods, while others operate only in batch or streaming mode. For a complete list of _Data 360_ connectors and available methods, check out [Data 360\: Integrations and Connectors](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5).

- **Real-Time\:**
  - Provides sub-second ingestion using _Change Data Capture (CDC)_
  - Suitable for time-sensitive workflows (for example, fraud detection, personalization, and operational dashboards)
  - Features push transformations and aggregations within _Data 360_, which helps to reduce downstream I/O and optimize compute usage
  - Supports using incremental CDC to minimize data shuffling
- **Streaming\:**
  - Provides ingestion every 1–3 minutes in small increments
  - Balances freshness and cost
  - Suitable for campaign orchestration, near-live engagement, and operational reporting
  - Supports using micro-batches to control I/O spikes
  - Aggregates data at the source (if possible) to reduce transfer volumes and optimize storage
- **Batch (Scheduled Loads)\:**
  - Provides periodic ingestion of large datasets (for example, hourly, daily, and weekly)
  - Provides cost-efficiency and reliability for historical datasets, regulatory reporting, and compliance use cases
  - Ensures that compute locality is in the same region as the source storage to enhance performance and optimize costs

#### Architect Playbook

- **Data Ingestion Use Cases\:**
  - **Generate Customer 360 Unified Profiles.** Build a single source of truth for customer identities and attributes.
  - **Maintain regulatory compliance datasets.** Enforce governance, lineage, and auditability for sensitive data.
  - **Centralize campaign orchestration.** Ensure that marketing, sales, and service all operate from consistent, trusted datasets.
- **Design Practices\:**
  - Accommodate batch ingestion for historical or low-latency-tolerant needs (for example, archival reporting or periodic snapshots).
  - Use CDC or streaming APIs to maintain freshness for operational and personalization workflows to ensure near real-time updates.
  - Control storage and compute growth by applying incremental loads to optimize cost and efficiency (rather than reloading entire datasets).
  - Align ingestion pipelines with compute locality and incremental processing to reduce network I/O.
  - Apply transformations inside _Data 360_ to avoid moving raw data unnecessarily.
- **Cost Considerations\:**
  - **Real-Time Ingestion** has the highest compute and pipeline costs, which may be justified for high-value, time-sensitive workflows (for example, personalization, operational dashboards, or Agentforce-driven actions).
  - **Streaming Ingestion** has moderate compute and storage costs, which may be suitable for frequent updates that can tolerate slight delays (for example, campaign orchestration or operational reporting).
  - **Batch Ingestion** has lower compute costs and predictable storage, which is suitable for historical datasets or low-frequency updates. Ingesting batch data from Salesforce orgs using certain connectors is free.
  - **Refresh Mode** Allows you to select _Incremental Refresh_ mode, which reduces total ingestion and compute costs. At Salesforce, we recommend using _incremental refresh_ wherever possible to optimize efficiency across all ingestion types.
  - **Cost** is also impacted by I/O volume from the source to _Data 360_. Optimizing batch sizes, partitions, and regional alignment reduces transfer costs and improves performance.
- **Industry Scenarios\:**
  - **Finance\:** Ingestion datasets are required for _knowing your customer (KYC)_, _Anti Money Laundering (AML)_, and fraud detection where auditability and compliance are non-negotiable.
  - **Healthcare\:** Use ingestion for patient identity resolution and HIPAA-compliant records, which enables secure, unified views.
  - **Retail\:** Consolidate _point of sale (POS)_, eCommerce, and loyalty program data into unified profiles for segmentation and personalization.
  - **Telecom\:** Support churn prevention and usage analytics with canonical, governed subscriber data.

#### Data Ingestion Method Decision Criteria

| Feature                              | Real-Time Ingestion                                                                                                                                                                         | Streaming Ingestion                                                                                                                                           | Batch Ingestion                                                                                                                                                                            |
| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Latency and Freshness**            | Features sub-second latency ingestion via Ingestion APIs with _Change Data Capture (CDC)_ support. Provides continuous streaming pipelines. Suitable for low-latency operational use cases. | Features micro-batch ingestion every 1–3 minutes via native connectors. Supports incremental updates. Slight latency is expected.                             | Data latency is expected. Allows scheduled large-volume loads. Features periodic ingestion (hourly, daily, and weekly). Not suitable for time-sensitive operations.                        |
| **Primary Use Cases**                | Ideal for low-latency operational and personalization use cases. Use for time-sensitive workflows. Supports event-driven workflows. Use for real-time fraud alerts and operational alerts.  | Suitable for moderately urgent processes. Use for campaign orchestration, near-live engagement, and operational reporting. Use for timely campaign triggers.  | Cost-efficient for massive datasets. Reliable for historical analytics. Use for historical aggregation or regulated reporting workflows. Suitable for historical or low-velocity datasets. |
| **Architectural Complexity and I/O** | Includes high cost and complex architecture. Requires low-latency source systems. I/O intensive. High-volume sources can cause saturated pipelines.                                         | Features simpler architecture than real-time. I/O is moderate. Suitable for predictable, repeated update patterns. Batch size impacts memory and computation. | Easy to implement. I/O intensive during load windows. Network throughput may become a bottleneck for large batches.                                                                        |
| **Cost Considerations**              | Includes the highest compute and pipeline costs. Justifiable for high-value, time-sensitive workflows only.                                                                                 | Includes moderate compute and storage costs. Provides a balanced cost vs freshness approach. Suitable for frequent updates that can tolerate slight delays.   | Features lower compute costs and predictable storage. Recommended for historical datasets or low-frequency updates. Ingestion via Salesforce internal pipelines is free.                   |
| **Design Practices**                 | Use incremental CDC to minimize data shuffling. Filter and use selective fields to reduce overhead.                                                                                         | Use micro-batches to control I/O spikes. Consider windowed aggregation to reduce processing load.                                                             | Use for archival reporting or periodic snapshots. Ensure that compute locality is in the same region as source storage for cost optimization.                                              |

### Zero Copy Data Federation

#### Zero Copy Use Cases

Use _Zero Copy_ for real-time querying of external systems without data duplication to enable agility, freshness, and scalable access to large or transient datasets. It's suitable for live dashboards, exploratory analytics, AI/ML model training, and real-time customer engagement directly through Salesforce _Data 360_.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Zero Copy Data Federation Overview" />

#### Zero Copy Methods

When using _Zero Copy_, architects must choose between three available data federation methods, each of which offers its own tradeoffs between freshness, performance, and cost.

- **Live Query**
  - Runs queries directly against external systems (for example, _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_, and so on) with no data duplication.
  - Minimizes data movement over the network and reduces I/O on the Salesforce _Data 360_ computation, which is optimal when predicates and aggregations can be pushed down.
  - Suitable for real-time insights and low-latency operational dashboards.
  - Dependent upon external system performance.
- **Caching (Accelerated Query)**
  - Temporarily stores cached copies of federated data in Salesforce _Data 360_.
  - Reduces repeated query costs and latency for frequently accessed datasets with configurable duration (minutes to days).
  - Data isn't permanently copied or fully governed, so freshness is managed via scheduled refreshes from the source.
  - _Incremental refresh_ supports upserts only. Deleted records aren't removed from the cache.
  - Perform a full refresh periodically to ensure that the cache remains in sync with the source.
  - **Note\:** The _Snowflake_ connector supports the _Unload_ function, which enhances acceleration rates by using a Snowflake-initiated staging bucket. This is enabled by default, but it can be disabled by editing the connection.
- **File Federation**
  - Provides direct, read-only access to large-scale datasets in object stores (for example, _S3_ and _GCS_ with _Iceberg_).
  - Suitable for AI/ML workloads, historical analytics, and petabyte-scale reporting without moving data.
  - Query performance depends heavily on object format, partitioning, and network I/O. Large scans may generate substantial I/O if they aren't optimized.

#### Architect Playbook

- **Use Cases**
  - **Real-time personalization and adaptive workflows** deliver dynamic offers, recommendations, and next-best actions as customer behaviors change.
  - **Live dashboards and operational analytics** power business-critical dashboards and KPIs directly from external warehouses.
  - **AI/ML model training with large external datasets** leverage petabyte-scale data from data lakes and warehouses without moving it via file federation.
- **Industry Scenarios**
  - **Retail/Media\:** Enable personalized recommendations and real-time customer engagement by federating clickstream or content interaction data.
  - **Finance\:** Run fraud detection and risk scoring in near-real time by querying external warehouses without duplicating sensitive data.
  - **Tech/Enterprise\:** Support cross-cloud reporting, IT service dashboards, and operational analytics when datasets reside in multiple systems.
- **Design Practices**
  - **Live Query**
    - Use for high-QPS, low-latency queries when freshness is critical.
    - Push predicates and aggregations to the external system to reduce data shuffling over the network.
    - Avoid queries that unnecessarily scan massive data volumes.
    - Consider partition pruning and filters instead.
  - **File Federation**
    - Access petabyte-scale datasets in object stores without ingestion.
    - Minimize latency and egress costs by keeping object storage in the same Cloud region as Salesforce computation.
    - Use partitioned, columnar formats (Parquet/ORC) and pushdown filters to reduce I/O and network transfer.
    - Leverage query and predicate pushdown to filter and aggregate data at the source, which reduces data movement.
    - Avoid cross-region data access—unless it's absolutely necessary—because it increases I/O, latency, and costs.
  - **Caching (Accelerated Query)**
    - Cache frequently accessed datasets to balance cost and performance.
    - Configure refresh intervals to balance freshness vs. query cost.
  - **Compliance\:** Enforce governance at the source by leveraging _row-level security (RLS)_ and masking policies directly within federated systems.
    - Here are a few best practices for uniform RLS and masking across platforms\:
      - **Use a Centralized Enterprise ID.** Map users and entities in Salesforce _Data 360_ to a unique, centralized enterprise identifier that corresponds to identities in external systems.
      - **Align Security Policies.** Ensure that RLS and masking policies in federated systems are applied based on the mapped identity. This preserves compliance when querying external data.
      - **Standardize Identity Schemas.** Maintain consistent identity attributes (email, user ID, customer ID, and so on) across all data sources to avoid mismatches and access violations.
- **Cost Considerations**
  - **Live Query\:** In the pay-per-query model, costs accrue on external lake house computation, which may cause spikes with high QPS. This is suitable for freshness-critical use cases where the value is greater than the cost variability.
  - **Accelerated Query (Caching)\:** This method lowers query cost (as compared to _Live Query)_ by reducing hits to the source system; however, it adds to batch data ingestion costs for filling and refreshing the cache. This is suitable for frequently-accessed datasets.
  - **File Federation\:** This is the cheapest storage option as data in Object Store; however, query costs depend on the file size, partitioning, and pruning. This is suitable for historical or bulk data at petabyte scale.

#### Zero Copy Method Decision Criteria

| Decision Point           | Live Query                                                                                                                                                                                                                    | Caching (Accelerated Query)                                                                                                                                | File Federation                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Data Source Location** | External data lake houses (for example, _Snowflake_, _Google BigQuery_, _Redshift_, and _Databricks_)                                                                                                                         | External data lake houses (for example, _Snowflake_, _Google BigQuery_, _Redshift_, and _Databricks_)                                                      | Object Stores or Cloud data lakes (for example, _S3_, _ADLS_, and _GCS_), which often use open-table formats like _Iceberg_.                                                                                                                                                                                                                                                                                                                                                     |
| **Purpose/Use Case**     | Suitable for interactive analysis and real-time dashboards. Suitable for real-time personalization and dynamic workflows.                                                                                                     | Suitable for when queries are frequent, but slightly stale results are acceptable. Suitable for BI dashboards and segmentation.                            | Suitable for large-scale batch processing and AI/ML model training. Suitable for historical analytics and petabyte-scale reporting.                                                                                                                                                                                                                                                                                                                                              |
| **Freshness/Latency**    | Provides maximum freshness Runs queries directly in real time. Supports sub-second decisioning when the source system is optimized for low-latency queries with effective predicate pushdown.                                 | Use when slightly stale results are acceptable. Freshness depends on the cache interval, which is configurable from 15 minutes to 7 days.                  | Suitable for batch-heavy, throughput-intensive jobs. Not suitable for real-time dashboarding.                                                                                                                                                                                                                                                                                                                                                                                    |
| **Access Pattern**       | Suitable for infrequent or ad-hoc queries where freshness is critical and query volume is low. Costs spike significantly at high QPS, so it's important to evaluate caching (Accelerated Query) when query frequency is high. | Suitable for high-frequency read scenarios. Improves performance for frequent access patterns.                                                             | Provides r*ead-only* access. Suitable for petabyte-scale datasets without ingestion.                                                                                                                                                                                                                                                                                                                                                                                             |
| **Performance Drivers**  | Highly dependent upon external source system performance. Suitable for when predicates and aggregations can be pushed down to the source.                                                                                     | Reduces latency when compared to repeated live queries. Performance depends on cache management and intervals.                                             | Performance depends heavily on object format, partitioning, and external system throughput. Use partitioned, columnar formats (Parquet/ORC).                                                                                                                                                                                                                                                                                                                                     |
| **Cost Implications**    | This is a pay-per-query model, so costs accrue on external lake house computations. It's cost-effective for infrequent queries, but expenses may spike with high QPS volume.                                                  | The cost is lower than repeated live queries. It reduces the need to repeatedly query the external source, but it adds cache storage and refresh overhead. | This is the cheapest storage option. For same-region, same-cloud AWS setups (for example, _S3_ in US-East-1 with a _Data Cloud_ tenant that's also in US-East-1), credits aren't consumed for the rows that are accessed. Cross-region or cross-Cloud configurations (for example, _Azure_, _GCS_, or different _AWS_ regions) incur credit consumption for the rows that are accessed. Query costs also depend on file size, partitioning, and predicate pushdown optimization. |
| **Key Consideration**    | Avoid unfiltered queries that scan massive data volumes unnecessarily.                                                                                                                                                        | This approach requires cache management. Not suitable for sub-second decisioning.                                                                          | Query performance relies heavily on optimization via partitioning and predicate pushdown.                                                                                                                                                                                                                                                                                                                                                                                        |

### Hybrid Approach

Hybrid architectures enable architects to anchor critical datasets in _Data 360_ for centralized governance while also leveraging federated queries for freshness, reduced duplication, and scalable access to large, external datasets. This approach balances I/O, compute locality, cost, and compliance requirements.

#### Hybrid Use Cases

Use a hybrid approach for balanced governance, freshness, and operational efficiency by combining data ingestion and zero copy to deliver real-time, actionable insights. Use ingestion for high-value, regulated datasets where traceability, RLS, and masking are required, and federation for ephemeral or high-volume datasets where freshness and performance are key.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="Hybrid Approach Overview" />

#### Architect Playbook

- **Use Cases**
  - **Omni-channel engagement\:** Blend historical customer data with real-time behavior to deliver consistent, context-aware experiences.
  - **AI/ML pipelines\:** Train models on curated, canonical datasets while enriching them with raw or real-time signals from external sources.
  - **Mixed compliance and agility needs\:** Apply strict governance for sensitive data, and federation for operational agility.
- **Industry Scenarios**
  - **Retail\:** Use _ingestion_ for identity resolution and profile unification, and _federation_ for real-time offers and personalization.
  - **Healthcare\:** Maintain golden patient records via _ingestion_ while using _federation on_ IoT device streams and sensor data for immediate context.
  - **Financial Services\:** Ingest regulated data into a compliance-governed lake while using _federation_ for external fraud-detection and risk-monitoring queries.
- **Design Practices**
  - **Anchor Governance with Ingestion\:** Ingest high-value or regulated data into canonical models to ensure trust and compliance.
  - **Use Federation for Freshness\:** Allows external lake houses to provide real-time or large-scale data access without duplication.
  - **Balance Cost vs. Performance\:** Profile workloads to determine when to use _ingestion_ vs. _federation_, which minimizes unnecessary storage and query costs.
  - **Apply Layered Governance\:** Enforce centralized governance for ingested data while leveraging the federated systems security controls (for example, RLS and masking).
  - **Note\:** When you're designing hybrid pipelines, it's important to ensure incremental ingestion for historical datasets and push aggregations or filters to federated sources to optimize I/O and compute usage.
- **Cost Considerations**
  - Weigh the total cost vs. performance by combining _ingestion_ for compliance or critical data with _federation_ when freshness is necessary.
  - Account for I/O and compute distribution when mixing _ingestion_ and _federation_. To reduce the compute cost of repeated queries against source systems, use caching (Accelerated Query) for high-read, frequently-accessed federated datasets.
  - Use this rule to guide the ingestion vs. federation decision\: when data is accessed frequently but changes infrequently, _Accelerated Query_ is typically more cost-effective. However, when data changes frequently (relative to access frequency), _Live Query_ or _ingestion_ is more appropriate. Here are a few cost examples\:
    - **Acceleration wins\:** A dashboard that's built from 1M records and updated daily with \~10K changes is viewed 20 times per day. _Acceleration_ costs equate to roughly \~600 credits/month vs. \~4,200 credits/month for _Live Queries_.
    - **Live Query wins\:** Segments that are published 20 times per day using data that changes every 30 minutes. _Live Queries_ cost roughly \~4,200 credits/month vs. \~28,800 credits/month for _acceleration_ at this refresh frequency.

## Use Case Decision Guide

Let's take a closer look at a few common archetypes that illustrate how to apply this logic.

- **The "Single Source of Truth" Archetype\: Centralize and Govern**
  - **Scenario\:** You need to build compliant, unified _Customer 360_ profiles for your entire global enterprise. The data comes from a dozen different systems, it must adhere to strict _GDPR_ and _CCPA_ regulations, and it will serve as the source of truth for all marketing and service interactions.
  - **Recommended Pattern\:** **Data Ingestion.** The priority here is governance, trust, and control. Ingesting the data into _Data 360_ is the only way to create a fully auditable, canonical profile that's insulated from the source systems.
- **The "Real-Time Insights" Archetype\: Analyze Without Moving**
  - **Scenario\:** Your data science team needs to run exploratory queries on a massive, constantly updating transaction table in _Snowflake_. At the same time, your executive team wants a live _BI_ dashboard that's powered by that same data. Moving petabytes of data daily is slow and expensive.
  - **Recommended Pattern\:** **Zero Copy Federation.** The priority here is speed, agility, and cost-efficiency at scale. _Zero Copy_ allows you to leverage the power of your existing data warehouse for real-time queries without the overhead and latency of data duplication.
- **The "Hybrid Intelligence" Archetype\: Govern the Core, Federate the Edge**
  - **Scenario\:** You want to enrich your governed, ingested customer profiles with real-time behavioral signals (for example, website clicks) from a data lake. You need the stability of the core profile but the immediacy of the live data to power in-the-moment personalization.
  - **Recommended Pattern\:** **A Hybrid Approach.** Use _Data Ingestion_ to create a stable, governed core for your customer data. Use _Zero Copy_ to federate the volatile, real-time "edge" data, and then join them together at query time for a complete, up-to-the-second view.

## The Path Forward

Enterprise data strategy is no longer focused on choosing a single integration pattern—it's about architecting controlled flexibility within an interoperable data ecosystem. The correct approach maps each source system to the pattern that best suits its freshness, governance, cost, and access requirements\:

- Ingest mission-critical, regulated datasets into Salesforce _Data Cloud_ for compliance, identity resolution, and operational workflows.
- Federate data via _Zero Copy_ for live, exploratory, and AI-driven analytics without duplicating storage.
- Apply _Caching (Accelerated Query)_ to reduce source system load and credit consumption when query frequency is high and data change frequency is low

Salesforce _Data 360_ on _Hyperforce_ delivers multi-region resilience and scalability. Its open lake house with _Iceberg_ tables enables computation separation and interoperability with platforms like _Snowflake_, _Databricks_, and _S3 Iceberg, which_ forms the backbone of a truly interoperable, multi-cloud data ecosystem.

As data ecosystems evolve, we must continuously balance freshness, cost, performance, and compliance to maintain architectural agility. That's why it's important to future-proof your platform by unifying ingested, governed data with federated access. This enables real-time intelligence, AI activation, and enterprise-scale personalization across Clouds, regions, and business domains.

Keep in mind that one-size-fits-all solutions don't suit most businesses. The optimal strategy maps the correct pattern to the correct business driver.

## About the Authors

**Yugandhar Bora** is a Software Engineering Architect at Salesforce who specializes in data architecture within the Data and Intelligence Applications platform. He leads _enterprise architecture review board (EARB)_ initiatives that focus on data governance and unified data models while also contributing to automated platform provisioning solutions.

**Jan Fernando** is a Principal Architect in the _Office of the Chief Architect (OCA)_ at Salesforce who joined Salesforce in 2012\. He brings a wealth of experience from his time in the startup ecosystem. Prior to joining the OCA, he spent over a decade in the _Platform_ organization, where he led several key technology transformations.

<!-- document id=e666fe45a0dfd2a93376248c3e5faeacb1dcc45d9a4a4b2c1a3a513a9d272d3e url=/architect/next/en-us/decision-guides/guides/data-360-provisioning.md -->

# Data 360 Provisioning

Salesforce Data 360 is a data platform built on [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) that unifies Salesforce and external data into a clear, complete, and trusted 360-degree view of every customer or account.

Enterprises often operate multiple Salesforce orgs due to mergers and acquisitions, regional operations, functional separation, or for historical reasons. Architects have several decisions about Data 360 to make, all of which impact governance, compliance, cost, latency, and the organization’s ability to scale AI and cross-org platform features.

## Guide Overview

This guide provides a framework for making provisioning decisions with Data 360. These decisions include:

- Selecting a single home org versus a multi-org configuration

- Provisioning multiple independent Data 360 instances

  - Use Data Cloud One to unify orgs under a single instance

  - Collaborate between independent Data 360 instances that use data sharing between Data 360 orgs

Data 360 is provisioned automatically on any production org that receives a Data 360 license. Data Cloud One is Salesforce’s multi-org connectivity architecture that allows a single home org to host the Data 360 instance, while other Salesforce orgs connect as companion orgs. The choice of which org holds the Data 360 license, and thus becomes a Data 360 home org, is a critical architectural decision with long-term consequences.

How you provision Salesforce Data 360 is a foundational architectural decision. It determines how the enterprise unifies customer data, enforces governance, and enables critical platform features, especially AI, Agentforce, and analytics across the organization. Anchoring a cluster of orgs to a single Data 360 provides a unified data model, centralized governance, and enables enterprise-wide AI readiness. Companion orgs can access shared metadata and features as if the data were local. By contrast, multiple independent Data 360 instances are appropriate when regulatory, compliance, or autonomy requirements prevent centralization. Data sharing between Data 360 orgs enables selective, zero-copy collaboration between these instances.

This decision influences who controls data governance, where data resides, how platform features are enabled, and how smoothly future integrations and AI initiatives can scale. Even for orgs that don’t currently have Data 360, it can be important to future-proof their architectures by developing a strategy for adding Data 360 access going forward. Increasingly, Salesforce features across Sales, Service, Marketing, Commerce, Industries, and Agentforce are built on Data 360\. Orgs that want to use these platform features must provision their own Data 360 or connect to a shared Data 360 as companion orgs.

This guide helps architects design a provisioning strategy that balances simplicity, enterprise-wide consistency, compliance, and scalability, ensuring the organization can confidently leverage Data 360 for Customer 360, AI, and cross-platform innovation. Use this guide to determine which orgs require Data 360, and whether to use Data Cloud One or data sharing between Data 360 orgs. This strategy establishes a firm groundwork for a Data 360-centric future.

## Products in Scope

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/data360-logo.png" alt="Salesforce Platform logo"></td>
      <td>Salesforce Data 360 is Salesforce's real-time, hyperscale data platform that harmonizes and unifies data from any source (CRM, web, mobile, or external data lakes) into a single, actionable customer profile. As a critical component of the <a href="https://www.salesforce.com/products/what-is-customer-360/">Customer 360</a> platform, it powers AI, analytics, and personalized experiences across sales, service, and marketing.</td>
    </tr>
  </tbody>
</table>

## Takeaways

- **Every org should plan for access to a Data 360 instance.** Each org must either host a Data 360 home org or be a companion org connected via Data Cloud One.

- **Think enterprise-wide, not org-by-org.** Avoid unilateral, line-of-business decisions made in isolation. Ideally an enterprise architecture or data governance council should collectively decide on the provisioning strategy. Always anticipate future AI and analytics needs, which depend on broad, unified datasets.

- **Plan governance and ownership early.** Decide whether to manage Data 360 centrally (Center of Excellence model) or delegated to lines of business. Define roles for admins, security teams, and compliance leads. Avoid ambiguity, as unclear ownership can be problematic.

- **Remember, provisioning is tied to licensing.** The org where the Data 360 license is purchased, determines where Data 360 is provisioned and that org’s location determines the region.

- **Understand data source support considerations.** Pay close attention to what regions are supported for various public clouds and zero-copy data sources. Also, determine if Private Connect is required for your security posture to connect to those data sources and if in-region or cross-region connections are supported.

- **Provision based on whether you have a single-org or multi-org.** For single-org customers, provision Data 360 in your existing production org for the fastest time-to-value. For multi-org customers, minimize complexity by creating the least number of Data 360 instances as possible, ideally by using Data Cloud One configuration.

- **Use** **multiple Data 360 instances only when necessary.** Multiple instances should only be used when required by compliance, residency, or organizational autonomy. In these cases, use [data sharing](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5) between Data 360 orgs to enable secure collaboration.

- **Set up data sharing between Data 360 orgs for collaboration, not for custom ETL pipelines.** Share specific objects (DMOs, calculated insights, segments) via data shares. Remember, tags aren’t shared, and consumption is billed to the source org.

- **Avoid short-term shortcuts.** Don’t spin up multiple Data 360 orgs for proof of concepts (POCs) without a long-term plan. Align pilots and early deployments to your enterprise-wide provisioning strategy.

## Decision Points

Evaluate every provisioning choice (choosing between Data Cloud One, data sharing between Data 360 orgs, or home org designation) against these cross-cutting considerations.

<table>
  <tr>
    <th>Consideration</th>
    <th>Why It Matters</th>
    <th>Example Scenarios</th>
  </tr>
  <tr>
    <td>Data Residency and Compliance</td>
    <td>Determines where data is stored and processed. Regulatory rules may require specific regions or multiple instances.</td>
    <td>A global bank provisions a Data 360 tenant on a Salesforce org geolocated in Frankfurt for GDPR compliance. They provision another tenant on an org in Virginia for its US division.</td>
  </tr>
  <tr>
    <td>Governance and Security</td>
    <td>Identify an admin and ownership of Data 360, including policy management and delegation strategies.</td>
    <td>A multinational with strong central IT creates a dedicated home org managed by a Center of Excellence.</td>
  </tr>
  <tr>
    <td>Autonomy vs. Centralization</td>
    <td>Different leaders may want separate ownership of data. Autonomy favors multiple Data 360 orgs. Centralization favors Data Cloud One.</td>
    <td>A holding company with independent subsidiaries allows each BU to run its own Data 360.</td>
  </tr>
  <tr>
    <td>Latency and Performance</td>
    <td>Impacts query speed and experience, especially for companion orgs connected to a Data 360 tenant across regions.</td>
    <td>A sales team in London querying data from a Data 360 tenant in the US may see higher latency.</td>
  </tr>
  <tr>
    <td>Integration Complexity</td>
    <td>More Data 360 tenants = more pipelines, APIs, and middleware. Consolidation simplifies integration.</td>
    <td>A retailer avoids building 10 ETL pipelines by consolidating into a Data Cloud One configuration.</td>
  </tr>
  <tr>
    <td>Zero Copy Data Source Region</td>
    <td>The cross-region access requirements for some connectors can limit the region or location of your Data 360 org.</td>
    <td>A company has a Snowflake instance in the AWS eu-west-1 region. They can use Zero Copy to federate data to a Data 360 in their region, but can't use Zero Copy to federate to a Data 360 in the US region.</td>
  </tr>
  <tr>
    <td>Private Connect Cross-Region Compatibility</td>
    <td>Sometimes, Private Connect support depends on whether the data source is in the same region as the Data 360 tenant.</td>
    <td>A company has a Snowflake instance in the aws-east-1 region that they want to connect to Data 360 via zero-copy. They can only establish a Private Connect network connection if the Data 360 home org is in the same region.</td>
  </tr>
  <tr>
    <td>Cost and Licensing</td>
    <td>Each Data 360 tenant adds cost. Consolidating into fewer instances optimizes spend.</td>
    <td>A healthcare provider reduces licensing costs by adopting Data Cloud One instead of multiple independent Data 360 instances.</td>
  </tr>
  <tr>
    <td>Future Scalability</td>
    <td>Provisioning choices today set the foundation for growth.</td>
    <td>A SaaS company starts with a single Data 360 instance but plans to expand to Data Cloud One as it acquires subsidiaries with Salesforce orgs.</td>
  </tr>
  <tr>
    <td>Enterprise-Wide AI Readiness</td>
    <td>AI features and Agentforce require a connected Data 360 tenant in every org. Provisioning decisions affect how AI models train and activate across the enterprise.</td>
    <td>A financial services company unifies data in Data Cloud One so its Einstein AI models have access to enterprise-wide customer data.</td>
  </tr>
</table>

## Use Cases

There are three major use cases that require decisions for Data 360 provisiong:

- Choosing the Home Org
- Applying a Multi-Org Strategy
- Sharing Data Between Data 360 Orgs

### Choosing the Home Org

When you purchase a Data 360 license, the Data 360 instance is provisioned in the Salesforce org associated with that license. This org is referred to as the Data 360 home org. The home org is the anchor for your Data 360 instance. This includes the:

- Management of Data 360 storage and compute (in the region selected at provisioning).

- Application of administration, governance, and security policies

- Performance of data ingestion, harmonization, identity resolution, segmentation, and activation

In multi-org scenarios, the home org manages the central Data 360 instance for other Salesforce "companion" orgs.

**The Home Org:**

- Determines the geographical location of your Data 360 instance.

- Determines who owns and administers your Data 360 instance. Admins in your Data 360 home org can access all data ingested into Data 360\.

- Controls companion org connections in a Data Cloud One configuration.

- Sets the foundation for your enterprise data strategy—changing it later is difficult and disruptive.

For more information on Data 360 home orgs, see [Data 360 Integration Patterns and Practices](/docs/architect/fundamentals/guide/data360_integration_patterns_and_practices).

#### Decision: Existing Org or New Org as the Home Org?

The first major decision is whether to provision Data 360 in an existing production org or to create a new, dedicated org to act as the home org.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="Decision diagram showing existing org vs new org as home org" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Option A: Provision Data 360 in an Existing Org**

**Works Best For:** Customers with a single Salesforce org, or multi-org customers who already have a major centralized org where most business processes run.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="Diagram showing Data 360 provisioning in existing org" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Pros:**

  - Simplest path: Data 360 is provisioned where your CRM data lives.

  - Immediate access to local Sales, Service, and Marketing data.

  - No additional integration is required.

  - Fewer licenses and environments to manage.

  - Accelerates early adoption, pilots, and production use cases.

- **Cons:**

  - Can inherit an existing org’s governance or technical debt.

  - If no single “main org” exists, selecting one can create ownership debates.

  - Performance tied to the org’s location; may not align with enterprise-wide residency needs.

  - If multiple business units use different orgs, local provisioning can lead to fragmentation if not paired with Data Cloud One.

**Example:**

A SaaS company with one Salesforce org provisions Data 360 in that org to unify customer subscription and support data.

**Option B: Provision Data 360 in a New, Dedicated Org**

**Works Best For:** Customers with multiple Salesforce orgs who can’t align on a single major org, or enterprises with a strong Center of Excellence (CoE) model.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="Diagram showing Data 360 provisioning in new dedicated org" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Pros:**

  - Clean slate for governance, with no inherited org complexities.

  - Centralized control across multiple lines of business.

  - Flexibility to choose a region based on compliance needs.

  - Acts as a neutral “shared service” org, not tied to one business unit.

  - Set up for future Data Cloud One architecture (home org with multiple companion orgs).

- **Cons:**

  - Customers must license a new Salesforce org on which to provision Data 360\.

  - Additional integration required to connect the org to a Data 360 via a Data Cloud One companion connection.

  - May add administrative overhead (user management, security, identity).

  - Slower time-to-value compared to provisioning in an existing production org.

**Example:**

A multinational financial services company creates a dedicated home org to provision Data 360\. All business unit orgs (Retail, Wealth, Commercial Banking) connect as companion orgs through Data Cloud One.

**Decision Criteria**

<table>
  <tr>
    <th>Consideration</th>
    <th>Existing Org as Home Org (Preferred Default)</th>
    <th>New Org as Home Org (Alternative)</th>
  </tr>
  <tr>
    <td>Simplicity</td>
    <td>Builds on existing user and data structure for faster setup.<br> Data 360 is integrated by default with the home org .</td>
    <td>Requires licensing and setup of a new Salesforce org, and additional administrative overhead to manage it</td>
  </tr>
  <tr>
    <td>Time-to-Value</td>
    <td>Immediate use of local CRM data</td>
    <td>Slower ramp and integration is required.</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Inherits existing org's basic governance model—existing users and permission sets (can be acceptable if the org is already central ).</td>
    <td>Clean slate for governance. Ideal for COE-led models.</td>
  </tr>
  <tr>
    <td>Compliance</td>
    <td>Residency tied to existing org's region</td>
    <td>Flexibility to select a region independent of existing orgs</td>
  </tr>
  <tr>
    <td>Performance</td>
    <td>Best performance for local CRM queries</td>
    <td>Dependent on companion org connectivity, whether it’s same region or cross-region to the other orgs</td>
  </tr>
  <tr>
    <td>Future Scalability</td>
    <td>Works well if paired with Data Cloud One. Harder to shift later if the wrong org is chosen</td>
    <td>Scales easily with Data Cloud One. Designed for neutrality.</td>
  </tr>
  <tr>
    <td>Cost</td>
    <td>Lower incremental cost</td>
    <td>Higher overhead from additional environments</td>
  </tr>
</table>

#### Recommendations

As a general principle, use an existing major org as your home org to minimize initial effort and accelerate adoption. Only create a new, dedicated home org if your long-term governance or compliance strategy requires it. Creating a new, dedicated home org is a common choice for larger enterprises with a Center of Excellence (COE).

**Single Org Environment**

Provision Data 360 in your existing production org. This maximizes simplicity and immediate value. It avoids unnecessary integration overhead.

**Multiple Org Environment**

Prefer to select one of your major orgs—typically the one where most of your business runs, or the org that serves as your centralized CRM—to act as the home org. This reduces complexity, minimizes setup work, and allows you to realize the value of Data 360 quickly. Using an existing major org also avoids the cost and integration effort of managing a new environment.

**When to Consider a New, Dedicated Home Org**

Creating a home org provides flexibility and neutrality, but with slower time-to-value in these cases.

- If your organization has a strong Center of Excellence (CoE) and wants governance separate from business unit orgs.
- If no single existing org is suitable due to compliance or organizational constraints.

### Applying a Multi-Org Strategy

#### The Multi-Org Challenge

Enterprises often operate multiple Salesforce orgs—and this isn’t an edge case, but the norm. As of February 2024, approximately 19,000 Salesforce customers already ran more than one Salesforce org.

Why does this happen?

- **Acquisitions and mergers:** Newly acquired companies bring their own Salesforce instances.
- **Regional operations:** Separate orgs for EU, North America, Asia-Pacific, and so on, often to satisfy data residency laws.
- **Functional separation:** Different business units (for example, Retail Banking, Wealth Management, Insurance) maintain their own orgs for autonomy.
- **Regulatory or security isolation:** Certain industries mandate logically distinct orgs for compliance reasons.
- **Historical or technical reasons:** Over time, customers organically accumulate multiple orgs.

Each reason makes sense individually, but together they create fragmentation of data. Without a unifying layer, each org only has a partial view of the customer.

The architectural challenge: How do you unify data across orgs into a single source of truth while respecting compliance, governance, and autonomy requirements?

---

#### Data Cloud One

Data Cloud One is Salesforce’s multi-org connectivity architecture that allows multiple Salesforce orgs to share a single Data 360 instance. It’s the recommended pattern for enterprises with multiple Salesforce orgs.

In any Data Cloud One cluster, one Salesforce org is designated as the home org, which hosts the Data 360 instance. Other Salesforce orgs connect as companion orgs, consuming the unified data and metadata from the home org’s Data 360\.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Diagram showing Data Cloud One architecture" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**How Data Cloud One Works**

- **Data Ingestion and Unification (Home Org)**

  - All data ingestion configuration (Salesforce CRM, external sources, streaming, batch) happens from the home org only.

  - The Data 360 tenant tied to the home org performs identity resolution, harmonization, modeling, and unification into trusted customer profiles.

  - Data 360 administration, governance policies, tagging, and masking are applied centrally from the home org.

- **Data Space Architecture**

  - From the home org, data is organized into data spaces, which act as logical containers for data, metadata, and processes.

  - Enterprises can create data spaces for brands, regions, or lines of business.

  - Data Space Sharing: From the home org, specific data spaces are selectively shared with companion orgs. This makes sure that only the relevant data (and associated metadata) flows to the right orgs.

- **Metadata Sharing**

  Companion orgs receive metadata definitions from the home org, including data model objects (DMOs), unified profile schema, calculated insights, segments, [and more](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). These appear natively inside the companion org as if they were local assets, but they’re linked to the home org.

- **Capabilities in Home Org vs. Companion orgs**
  Feature access differs between home and companion orgs. Companion orgs can’t ingest or unify data, and rely on the home org for ingestion, modeling, and unification. Companion orgs can access Data 360 data to power Data 360-powered platform features, and they can create local insights, segments, and flows on top of the shared, trusted data. In the future vision, they can also access activation features.

<table>
  <tr>
    <th>Capability</th>
    <th>Home Org</th>
    <th>Companion Org</th>
  </tr>
  <tr>
    <td>Connect Configure connectors, create data streams, ingest, or federate data</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Harmonize and Unify Build and run data transforms and identity resolution</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Govern Secure data with data space and permissions</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Segment and Predict Build segments, insights, and create Einstein Studio models</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Activate Everywhere activations, data actions</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Platform Features: Prompt Builder, Flows, Reports, Enrichment, [and more](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Data 360-Powered Features: Prospecting Center, Sales and Service Cloud features, Agentforce, and more</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
</table>

- **Platform Feature Parity**
  From the perspective of users and builders, once the metadata is shared, there are some functional differences between home and companion orgs in terms of using Salesforce platform features. List of supported features can be found in [Data 360 Features on Companion orgs](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5).

  - Salesforce platform features—such as Flows, Reports, Prompt Builder, dashboards, and other platform-native tools—work in both home and companion orgs once metadata is available.

  - Data 360-powered features—such as Agentforce, Prospecting Center, Sales Cloud Einstein features, and Service Cloud AI features—also work seamlessly in both home and companion orgs. Some features may be on their path to reach complete compatibility but the overall goal is to have feature parity between home and companion orgs for all cross-cloud features that depend on Data 360\.

- **Consumption Model**
  All companion org activity (queries, segment runs, Data 360-triggered flows, AI usage, Einstein Trust Layer logging, and so on) consumes Data 360 credits from the home org. Consumption flows one way: credits are centralized, billed, and tracked against the home org's credit allocation. However, you can drill down to see how many credits each individual org used in Digital Wallet.
- **Design Principle: Horizontal Construct**
  The horizontal construct in Data 360 is a foundational design principle, primarily implemented through Data Cloud One, that allows a single Data Cloud instance to span across multiple, distinct Salesforce CRM orgs. The goal is that every new released feature works in both home and companion orgs without additional setup. This functionality ensures Data Cloud One isn’t just a data architecture choice, but a foundational element of the Salesforce platform going forward.

---

#### Decision: Multiple Data Orgs vs. Shared Data 360 (Data Cloud One)

Enterprises with multiple orgs must choose how and where to locate Data 360 within their ecosystem. Do they want to provision independent Data 360 orgs in each org, or use Data Cloud One to unify orgs under a single home org?

**Option A: Multiple Independent Data 360 Orgs**

Each Salesforce org provisions its own Data 360 instance.

**Pros:**

- **Autonomy:** Each business unit or region controls its own Data 360\.

- **Simplicity within each org:** Governance, security, and customizations are localized.

- **Regulatory compliance:** Useful when strict regulatory separation is required (for example, data must not cross borders).

**Cons:**

- **Data silos:** Unified profiles can’t be achieved across orgs.

- **Higher cost:** Each instance requires licensing, administration, and integration. Customers end up ingesting the same source data multiple times across multiple different orgs.

- **Duplicate work:** Identity resolution, segmentation, and enrichment must be repeated in each Data 360 instance.

**Option B: One Shared Data 360 (Data Cloud One Cluster)**

A single Data 360 is provisioned in a home org, with other Salesforce orgs connected as companion orgs.

**Pros:**

- **Single Source of Truth (SSOT):** All orgs share a unified data model.

- **Cost efficiency:** Manage only one Data 360 license and infrastructure.

- **Unified governance:** Centrally applied policies, security, and compliance controls.

- **Cross-org enrichment:** Access harmonized profiles, insights, and segments across companion orgs.

- **AI readiness:** An enterprise-wide dataset enables better training and activation of AI models.

- **Future proof:** Adding new companion orgs is simple, as there’s no need for new Data 360 orgs.

**Cons:**

- **Additional preparation:** One Data 360 requires planning for org-to-home org connectivity.

- **Latency considerations:** Companion orgs in different regions may see slower queries.

- **Complex governance:** If each org has different customization needs, fine-grained governance can be complex.

**Option C: Multiple Data Cloud One Clusters**

**Sometimes**, governance, compliance, or other business requirements may make it impractical to cluster every org together. This may lead to a need to implement a hybrid solution in which the enterprise operates several Data 360 orgs, each of which is the home org for a different cluster of companion orgs.

**Example:**

A multinational corporation has Salesforce orgs in various regions, including Europe, the US, and Asia. To comply with regional data residency regulations, they provision one Data 360 for each separate region.

**Decision Criteria**

<table>
  <tr>
    <th>Consideration</th>
    <th>Multiple Independent Data 360 Orgs</th>
    <th>One Shared Data 360 (Data Cloud One)</th>
  </tr>
  <tr>
    <td>Autonomy</td>
    <td>High autonomy for each org or business unit</td>
    <td>Centralized governance, less autonomy per org</td>
  </tr>
  <tr>
    <td>Compliance</td>
    <td>Useful when strict separation is required (for example, regional laws)</td>
    <td>Works best when residency allows centralization</td>
  </tr>
  <tr>
    <td>Cost</td>
    <td>Higher licensing and admin costs</td>
    <td>More cost-efficient; one license for many orgs</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Fragmented; policies differ per org</td>
    <td>Centralized, consistent policies across orgs</td>
  </tr>
  <tr>
    <td>Data Silos</td>
    <td>Each org with its own view No enterprise 360</td>
    <td>Unified dataset, no duplication</td>
  </tr>
  <tr>
    <td>AI/Analytics</td>
    <td>Limited to each org's data</td>
    <td>Enterprise-wide models with better accuracy</td>
  </tr>
  <tr>
    <td>Complexity</td>
    <td>More instances to manage, more integrations</td>
    <td>Simpler architecture, fewer moving parts</td>
  </tr>
  <tr>
    <td>Performance</td>
    <td>Best for intra-org use cases</td>
    <td>Potential increase in latency with companion org access</td>
  </tr>
</table>

---

#### Recommendations

**Preferred Pattern: Data Cloud One**

To simplify governance and optimize cost across multi-org enterprises, use a single home org with connected companion orgs.

**When to Use Multiple Data 360 orgs:** Only use multiple Data 360 orgs if compliance, residency, or organizational autonomy strictly require it (for example, if European operations must remain fully separate from US operations due to regulation).

**How to Choose the Home Org in Data Cloud One:** Start by considering one of your major orgs, typically where most of the business runs. Provisioning Data 360 there can minimize complexity and maximize early value.

Consider creating a dedicated home org managed by a COE team, only if no existing org is suitable.

**General Principle:**

In multi-org environments, minimize the number of Data 360 orgs. Favor Data Cloud One as the default pattern to reduce duplication, enable AI readiness, and simplify governance.

### Sharing Data Between Data 360 Orgs

#### The Need for Data Sharing

While Data Cloud One is the recommended approach for most enterprises, there are scenarios where customers must provision multiple Data 360 instances, including:

- **Regional compliance.** A multinational retailer provisions one Data 360 in the EU and another in the US. Data 360-to-Data 360 data sharing allows the company to create insights from local data and still share the insight with US headquarters.
- **Business unit collaboration.** A conglomerate runs separate Data 360 orgs for Retail and Insurance. Data sharing between Data 360 orgs allows users to access a single, authoritative source of data without moving or copying. With data sharing between Data 360 orgs, the Insurance org receives Retail’s “High-Value Customer” segment for targeted cross-sell campaigns.
- **Mergers and acquisitions.** A parent company acquires a subsidiary with its own Data 360\. With two instances to manage, retaining short-term data silos preserves data security and SSOT integrity. Simultaneously, sharing data between two Data 360 instances allows necessary collaboration during the transition.
- **Federated executive dashboards.** A multinational spread across continents provisions individual Data 360 orgs per region. Executives want a federated quarterly performance view. Each regional Data 360 shares aggregated calculated insights with an “Executive Org,” enabling enterprise-wide reporting.

#### How Data Sharing Works

When multiple Data 360 orgs exist, unification across them isn’t automatic. Data 360 to Data 360 data sharing enables customers to share specific objects between Data 360 instances without duplication or custom pipelines. It’s a zero-copy metadata sharing mechanism designed for collaboration across Data 360 orgs.

- Each Data 360 is provisioned in its own home org.

- Administrators can create a data share—a grouping of specific objects they want to share.

- Access to the selected data is shared with a target org’s Data 360, where the objects appear as if defined locally. Only access is shared, the underlying data remains in the source Data 360\.

- Tags aren’t shared. Only the raw objects are made available; the target org must reapply any governance, operational, or AI tags as needed.

#### Key Differences from Data Cloud One

- In Data Cloud One, multiple companion orgs share a single Data 360 instance. To ensure consistency, Platform features like Agentforce, Prospecting Center, and Tableau Next, run on the same underlying data.

- When using data sharing between Data 360 orgs, each org has its own Data 360\. Features like Agentforce in Org A and Org B each operate independently on their local instance. No sharing occurs automatically—deliberate data shares must be created to collaborate on specific objects only.

#### Pros and Cons of Data Sharing between Data 360 Orgs

<table>
  <tr>
    <th>Factor</th>
    <th>Pros</th>
    <th>Cons</th>
  </tr>
  <tr>
    <td>Data Residency</td>
    <td>Supports regional separation while enabling collaboration.</td>
    <td>Does not remove the need to manage multiple Data 360 orgs.</td>
  </tr>
  <tr>
    <td>Data Duplication</td>
    <td>Zero-copy; no duplication of objects.</td>
    <td>Requires deliberate selection of objects for inclusion in each data share.</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Sharing is explicit and deliberate (object-level).</td>
    <td>No tags or policies flow; target org must reapply governance.</td>
  </tr>
  <tr>
    <td>Complexity</td>
    <td>Enables selective collaboration without centralization.</td>
    <td>Requires management of multiple Data 360 orgs and data shares.</td>
  </tr>
  <tr>
    <td>**AI/Analytics**</td>
    <td>Regional AI/analytics possible; insights can be shared across orgs.</td>
    <td>No enterprise-wide AI unless data is deliberately shared.</td>
  </tr>
  <tr>
    <td>**Platform Features**</td>
    <td>Each org's Data 360–powered features run independently.</td>
    <td>No automatic sharing. Duplication risk if not carefully designed.</td>
  </tr>
  <tr>
    <td>Cost</td>
    <td>May reduce the need for ETL pipelines.</td>
    <td>Still incurs the cost of multiple Data 360 orgs. Consumes credits for data queries and data sharing.</td>
  </tr>
</table>

#### Decision Criteria

<table>
  <tr>
    <th>Consideration</th>
    <th>Data Cloud One (Preferred for multi-org)</th>
    <th>Data Sharing between Data 360 Orgs</th>
  </tr>
  <tr>
    <td>Single Source of Truth</td>
    <td>Yes—all orgs share a data model.</td>
    <td>No—each Data 360 has its own data model.</td>
  </tr>
  <tr>
    <td>Compliance</td>
    <td>Works only when residency allows centralization.</td>
    <td>Needed when residency laws prevent centralization.</td>
  </tr>
  <tr>
    <td>Governance</td>
    <td>Centralized, consistent.</td>
    <td>Federated; deliberate object-level shares.</td>
  </tr>
  <tr>
    <td>Complexity</td>
    <td>Fewer moving parts, simpler.</td>
    <td>More complex—requires configuration data shares and multiple Data orgs.</td>
  </tr>
  <tr>
    <td>AI/Analytics</td>
    <td>Enterprise-wide AI models.</td>
    <td>Regional AI. Selectively share insights.</td>
  </tr>
  <tr>
    <td>Platform Features</td>
    <td>Shared Data 360 means all features work consistently across home + companions.</td>
    <td>Features run independently in each Data 360; sharing must be explicit.</td>
  </tr>
</table>

#### Recommendations

**If your enterprise has multiple Data 360 orgs**

- Use data sharing between Data 360 orgs to collaborate across them rather than building custom pipelines or duplicating data.

- Share specific objects (DMOs, calculated insights, segments) by creating data shares and granting them to target orgs.

- Tags aren’t shared—the receiving org must reapply tags, for governance, classification, or AI enrichment.

**Use data sharing between Data 360 orgs**

- To meet regulatory requirements that prevent centralization.

- To maintain business unit autonomy while enabling selective collaboration.

- To provide federated executive dashboards across multiple regions.

- To bridge M\&A scenarios where consolidation isn’t immediately possible.

**Design carefully**

Treat Data 360-to-Data 360 data sharing as a federation strategy, not as a replacement for Data Cloud One.

- Use object-specific sharing.
- Avoid over-sharing.
- Align data shares with business and compliance needs.

#### Remember

Planning your data strategy for Data 360 provisioning is a critical, long-term architectural decision that must be approached enterprise-wide, not org-by-org. This early strategic choice dictates how customer data is unified, how governance is enforced, and how essential platform features—especially AI and analytics—scale across the organization. Plan governance and ownership models up front and avoid short-term shortcuts that lead to fragmentation and increased complexity later.

## Resources

[What is Customer 360?](https://www.salesforce.com/products/what-is-customer-360/)

[Data 360 Integration Patterns and Practices](/docs/architect/fundamentals/guide/data360_integration_patterns_and_practices)

[Data 360 Architecture](/docs/architect/fundamentals/guide/data-360-architecture)

[Data 360 Security Architecture](/docs/architect/fundamentals/guide/data360_security_architecture)

**About the Authors**

Kunal Goyal is a Director of Product Management at Salesforce, focused on advancing multi-org architecture and scalability within Data 360\. Since 2017, he’s led multiple initiatives and products centered on cross-org collaboration and multi-tenant system design. Kunal is one of the Data 360 Best Practices Architecture Leads and the product owner for Data Cloud One, setup, provisioning, and admin experiences.

Erin Wagner Tidwell is a principal technical writer and content designer for Data 360\. She’s been at Salesforce since 2013\. She’s dedicated to making Data 360 easier to understand and use through clear, consistent, and accurate technical documentation and in-app communication.

Yugandhar Bora is a Software Engineering Architect at Salesforce, specializing in data architecture within the Data and Intelligence Applications platform. He leads enterprise architecture review board (EARB) initiatives focused on data governance and unified data models, while contributing to automated platform provisioning solutions.

Samarpan Jain is a Principal Architect at Salesforce specializing in Commerce Cloud, platform integration, and cross-org architecture. One of Salesforce's longest-tenured employees, he leads key initiatives including data residency compliance for government customers and Data 360 usage attribution systems.

<!-- document id=4f5f98f7255ff99d31650a2c434b6a6dc08132c1d7f7e89446885c2d6f51c45d url=/architect/next/en-us/decision-guides/guides/data-integration.md -->

# Data Integration with Salesforce

There are a multitude of ways to access, synchronize, and share data between Salesforce and external systems. But not every tool is right for your particular project. This guide walks through the landscape of data integration tools available from Salesforce. It also offers recommendations for the tools (or combinations of tools) that are most appropriate given a particular use case, as well as guidance on tools to avoid for specific scenarios.

## Guide Overview

This decision guide focuses on data-level integrations involving Salesforce. Specifically, it covers the following data integration use cases:

- Salesforce to external systems
- External systems to Salesforce
- Salesforce organization to Salesforce organization

These are only a subset of the integration challenges that Salesforce Architects face, so we plan on adding more decision guides focused on event-driven integration, building effective customer- or employee-facing workflows using process integration, and so on. Finally, it’s important to note that many of the tools and approaches described here can be used to solve integration challenges across the wider enterprise, but such uses are beyond the scope of this guide.

## Takeaways

- **Avoid unnecessary data replication.** Unless the data absolutely needs to reside in Salesforce, consider data virtualization with Salesforce Connect instead. More data in your organization ultimately leads to larger data volumes, which can adversely affect [performance](/docs/architect/well-architected/guide/reliability.html#scalability-and-capacity-planning) and add technical debt. If your data already resides in Salesforce and you need it in an external system, avoid copying it to an external system unless absolutely necessary. Instead, have the external system access the data via the Salesforce APIs.
- **Use MuleSoft or other Enterprise Service Bus (ESB) or Extract-Transform-Load (ETL) solutions, if available and part of your existing landscape.** Because these tools are built to help support data migration and transformation, they often have powerful capabilities that enable you to reuse integrations across the enterprise, maintain stronger governance, and centralize management of integrations. In this guide, wherever MuleSoft Anypoint is recommended, consider whether your existing ESB/ETL solution will suffice.
- **Harmonize data from different sources with Data 360 and Data Cloud One.** Through the Customer 360 Data Model, identity resolution, data federation, and other features, Data 360 consolidates data from Salesforce and other external systems into a unified view of your customer. And with [Data Cloud One](/docs/architect/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one), users in other Salesforce orgs can safely access data shared virtually from Data 360 through data spaces.
- Move data between orgs using **Data 360 actions and activations.** After data is ingested from different orgs into Data 360, data [actions and activations](/docs/architect/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) can sync the data to another org. This approach can be very useful for integrations with Marketing Cloud orgs.
- Extract and move data using **MuleSoft Anypoint.** MuleSoft Anypoint can be used to extract data from Data 360 using Connect API and Data Graph API and move it to another Salesforce org. Without Data 360, MuleSoft Anypoint can also be used when data needs to be moved between orgs without being replicated in Data 360\.
- **Use caution if you choose to build with Outbound Messaging.** Salesforce will continue supporting Outbound Messaging within current functional capacities, but does not plan on making further investments in this technology.
- **Integration user license with "API Only" profile is always recommended for all integrations.** Salesforce also recommends using External Client Applications (in favor of connected apps or SOAP login) as the properly permissioned AuthN and AuthZ patterns for all integrations.

## Common Considerations for Choosing Data Integration Tools

Before diving into the data integration tools available, it’s important to keep a few common considerations in mind when choosing a tool. As is typical with architecture, there is no prescriptive answer to every business challenge. If you’ve uttered the words “it depends” when making integration choices, then you’re in the right place.

<table>
    <thead>
        <tr>
            <th>Area to Consider</th>
            <th>Common Questions</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Existing Tools and Landscape</td>
            <td>Is there an existing ESB or ETL solution in place? Does the data involved have regulatory or compliance requirements? Where are the systems you're trying to integrate located (in the cloud or on-premise)?</td>
        </tr>
        <tr>
            <td>Data Flow (Timing, Expected User Experience, Directionality)</td>
            <td>Does the data need to move synchronously, asynchronously or can it be batched/scheduled? Is data replication required? What system should be the source of truth? What is the data source? What is the target destination? Is user interaction required? Does the user need to see the result of the integration? What are the needs around exception handling (retry, notify, fail)? How tightly-coupled should systems be?</td>
        </tr>
        <tr>
            <td>Implementation</td>
            <td>What is the level of effort for non-Salesforce systems? What teams are responsible for delivering integrations? What tools do they prefer to use?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/well-architected/guide/resource-and-cost-optimization.html#code-organization">Maintainability</a></td>
            <td>What teams will be expected to maintain the integration? What skills do they currently have? What skills will they need in the future? What is the total cost of ownership over time? How important is the ability to test, debug, troubleshoot with low or pro code tools?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/well-architected/guide/reliability.html#scalability-and-capacity-planning">Data Volume</a></td>
            <td>How much data is involved in the integration? Will you be working with <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">Large Data Volumes</a> (LDV)? How frequently will changes happen in bulk? What sort of impact will singleton updates have? How often will they occur?</td>
        </tr>
        <tr>
            <td>Limits</td>
            <td>Will the data need to undergo complex transformation? Does the data need to be combined from several source systems? How often will an integration take place on a per user basis? How many users total? Have you planned ahead for bulk data loads (example: initial data load for a new instance)?</td>
        </tr>
    </tbody>
</table>

## Product Comparison

Here is a high-level overview of the tools available for data integration and some considerations to start evaluating each option. The following sections include in-depth use cases and details about the capabilities of these tools.

<table>
    <thead>
        <tr>
            <th></th>
            <th>From Salesforce to External System</th>
            <th>From External System to Salesforce</th>
            <th>Execution</th>
            <th>Additional License Required</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex Actions</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Change Data Capture</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-no">Not Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No*</td>
        </tr>
        <tr>
            <td><strong>Custom Apex (REST and SOAP Web Services)</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>External Services</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-no">Not Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>Yes</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>Yes</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>Yes</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce APIs</strong></td>
            <td class="guide-table-no">Not Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Omniscript</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-no">Client-Side***</td>
            <td>Yes</td>
        </tr>
        <tr>
            <td><strong>OmniStudio Integration Procedure</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>Yes</td>
        </tr>
        <tr>
            <td><strong>Outbound Messaging</strong></td>
            <td>Not Ideal</td>
            <td class="guide-table-no">Not Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No</td>
        </tr>
        <tr>
            <td><strong>Platform Events</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>No**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/External Objects</strong></td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Available</td>
            <td class="guide-table-ok">Server-Side</td>
            <td>Yes</td>
        </tr>
    </tbody>
</table>

[\*Add-on required for high-volume change data capture event use cases](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm)

[\*\*Add-on required for high-volume platform event use cases](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

\*\*\*Suitable in situations where it's ok for business logic to run within the web browser.

Column legend:

- **Available**: works well for most use cases
- **Not Ideal**: possible but consider an alternative tool
- **Not Available**: no plans to support in the next twelve months

### Other tools for moving data into and out of Salesforce

There are other tools that may support some aspects of a data-layer integration, but must not be considered a primary means of solving integration problems. Let’s take a quick look at these tools now.

**Lightning Web Components** are typically used for process integrations, but they can make callouts using JavaScript functionality, so data could be involved in these transactions.

**Salesforce Flow** can be used to orchestrate external callouts with External Services or Apex Actions. Salesforce Flow by itself is not considered a standalone data integration tool.

**Data Import Wizard and Data Loader** can be used to synchronize, import, and migrate data. While Data Loader commands can also be scripted to automate the import and export of data, the [command-line interface](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) is for Windows only and neither of these tools is a recommended base for a data integration strategy. Instead, use them to complement your data stewardship and maintenance strategy.

[**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) data commands can be used to manipulate records in your org. Commands are available to help you import and export data with the Bulk API and SObject Tree Save API, and perform simple CRUD operations on individual records with the REST API. The Salesforce CLI by itself is not considered a standalone data integration tool.

**OmniStudio Data Mapper** can be used as a declarative ETL tool to move data between Salesforce objects and JSON data structures. While a REST interface is automatically created for each Data Mapper interface, providing a declarative way to move data from external systems to Salesforce objects, Data Mapper standalone is not a recommended base for a data integration strategy. Data Mapper actions are available in OmniStudio Integration Procedures.

[**Dataloader.io**](http://dataloader.io/) is another data loader tool for Salesforce powered by MuleSoft's Anypoint Platform allowing you to quickly and securely import, export and delete unlimited amounts of data for your enterprise. Dataloader.io is not a recommended base for a data integration strategy.

## Salesforce to External Systems (Outbound Integration)

For outbound integrations from Salesforce, you may consider different types of tools: low-code, pro-code, or a hybrid. The following sections provide guidance for each of these tool types and offer sample solutions.

- [Low-Code Tools for Outbound Integrations](#low-code-tools-for-outbound-integrations-from-salesforce)
- [Hybrid Tools for Outbound Integrations](#hybrid-tools-for-outbound-integrations-from-salesforce)
- [Pro-Code Tools for Outbound Integrations](#pro-code-tools-for-outbound-integrations-from-salesforce)

### Low-Code Tools for Outbound Integrations from Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Licensing</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>When to Use</strong></th>
            <th><strong>Additional License</strong></th>
            <th><strong>Sync (Request/Reply) or Async (Fire/Forget)</strong></th>
            <th><strong>Multi-Object Support</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Testing & Deployment**</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Built-In Error Handling/Retry Behavior</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong></th>
            <th><strong>Authentication Protocol</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Change Data Capture</strong></td>
            <td>When you need to publish record-level changes made in Salesforce to an external system and don't need a custom payload.</td>
            <td>Required</td>
            <td>Async</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>External Services</strong></td>
            <td>When you're orchestrating a process using Flow, Apex, Einstein Bots or OmniStudio and the external system APIs are described using OpenAPI specifications.</td>
            <td>Not Required</td>
            <td>Sync</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td>N/A</td>
            <td>Named Credentials</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>When you want to extend your data with bidirectional sync to enable mobile and other apps on Heroku, and you want the data to also be replicated to Salesforce.</td>
            <td>Required</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td>With pro code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes, via Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>OmniStudio Integration Procedure</strong></td>
            <td>When you need to transform data without user interaction and improve performance by processing on the server instead of the browser.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Declarative support</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Named Credentials</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/External Objects</strong></td>
            <td>When you want data to appear in the Salesforce UI, but want the data to be stored in an external system. Data is not replicated to Salesforce.</td>
            <td>Required</td>
            <td>Sync</td>
            <td>No</td>
            <td class="guide-table-ok">Yes*</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools & a declarative tracer</td>
            <td>No</td>
            <td>N/A</td>
            <td>Named Credentials</td>
        </tr>
        <tr>
            <td colspan="11">*OData adapters older than version 4.01 are subject to callout limits. See <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">OData Callout Rate Limit Considerations</a> for more details. ** Testing and Deployment refers to the ability to build in a lower environment and deploy via the <a href="https://developer.salesforce.com/docs/metadata-coverage/">Metadata API</a>, packages, or change sets to production.</td>
        </tr>
    </tbody>
</table>

### Use Case: Outbound Integration Using Low-Code Tools

> When opportunities are won, an order for the associated products needs to be created in the company’s ERP system or order management system.

**Change Data Capture** As Opportunity records are updated, Change Data Capture publishes change events that contain the updates to the objects. The change events are consumed on the customer’s side over a CometD connection (or via a MuleSoft connector) and used to update the customer’s ERP or order management system. Change events can be enriched to always include external record IDs or other data from the object (such as region) that are needed for the integration. Change event streams for multiple objects can be combined into _channels_ for simplified subscription and stream processing (so you can subscribe to and process one stream instead of many).

**External Services** If you have a web service that supports the OpenAPI 2.0 or 3.0 specification, you can expose the operations and services as an External Service within Salesforce. The API operations (for example create order) can be called as an Invocable Action in a flow built with Flow Builder when the stage of the opportunity is changed to "Won".

**Heroku Connect** Heroku Connect is typically used to keep a Heroku Postgres Database and Salesforce in sync. If the customer uses Heroku Postgres as their source-of-truth transactional store, then you can sync the records and the changes from Salesforce to Heroku Postgres using Heroku Connect. From there, you can use Heroku Streaming Connectors to publish those changes to Apache Kafka and send them as events to downstream applications, including the ERP or order management system.

**OmniStudio Integration Procedure** When an order is submitted, the Omniscript orchestrating the process can post the order details to an ERP or MuleSoft connector. The post can be executed either directly by the Omniscript (client-side) or indirectly via an Integration Procedure (server-side). If the ERP system throws a validation error, the Omniscript UI must notify the user, and if necessary, translate and contextualize the error for the user.

**Salesforce Connect/External Objects** You can create a record-triggered flow in Salesforce that inserts a record into the related external object(s) when the stage of the opportunity is changed to "Won". Since this is a [mixed transaction](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1), to avoid errors add a pause element for zero seconds between the Opportunity update and the related external object insert(s) so that you close one transaction context before you start a new one.

### Hybrid Tools for Outbound Integrations from Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Licensing</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>When to Use</strong></th>
            <th><strong>Additional License</strong></th>
            <th><strong>Sync (Request/Reply) or Async (Fire/Forget)</strong></th>
            <th><strong>Multi-Object Support</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Testing & Deployment**</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Built-In Error Handling/Retry Behavior</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong></th>
            <th><strong>Authentication Protocol</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex Actions</strong></td>
            <td>When you want to automate callouts to another system via Salesforce Flow. A developer can write an Apex class that a flow can invoke, or you can download a prebuilt solution from AppExchange.</td>
            <td>Not Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>Event Relays</strong></td>
            <td>When you need to send platform events and change data capture events to Amazon EventBridge from Salesforce. Event Relays only connect to AWS Eventbridge</td>
            <td>No</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>HTTP/1.1 with TLS</td>
        </tr>
        <tr>
            <td><strong>Outbound Messaging</strong></td>
            <td>When you need to send SOAP messages over HTTP(S) to a designated endpoint with guaranteed receipt when triggered by a workflow rule.</td>
            <td>Not Required</td>
            <td>Async</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>Declarative support</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Two-way TLS</td>
        </tr>
        <tr>
            <td><strong>Platform Events</strong></td>
            <td>When you need a custom-defined, structured payload for near real-time changes in Salesforce or an external system.</td>
            <td>Not Required*</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/External Objects (with custom Apex adapters)</strong></td>
            <td>When you want data to appear in the Salesforce UI, but want the data to be stored in an external system that cannot use standard protocols like OData or GraphQL.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td>N/A</td>
            <td>Multiple</td>
        </tr>
         <tr>
            <td><strong>Data 360</strong></td>
            <td>When you want harmonized data from different sources in one data store, or you want to replicate your data to other Salesforce orgs or to other external systems.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

[\*Add-on](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) required for high-volume use cases.

\*\*Testing and Deployment refers to the ability to build in a lower environment and deploy via the [Metadata API](https://developer.salesforce.com/docs/metadata-coverage/), packages, or change sets to production.

### Use Case: Outbound Integration Using Hybrid Tools

> When opportunities are won, an order for the associated products needs to be created in the company’s ERP or order management system.

**Apex Actions** A record-triggered flow based on the opportunity state can be triggered automatically when an opportunity is won. The flow executes an invocable action that uses an external callout to submit the order to the order management system or ERP solution. High-volume submissions and multisite orders are handled by Apex batch and queue mechanisms.

**Outbound Messaging** After [setting up outbound messaging](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm), you can define a workflow rule triggered by the opportunity update to send a SOAP message over HTTP(S) to a specified endpoint URL hosting the listener. The message will contain the fields specified when the outbound message was created. If the information in the object changes after the notification is queued, but before it is sent, only the updated information will be delivered and messages will stay in the queue until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue. If the ERP system requires additional data, you can pass the sessionId in outbound messages so the external system can make a callback request.

**Platform Events** You can define a platform event that includes the custom payload with the data required to create the records in the external system. Because Platform Events are not auto-published upon record change, you must publish the event via Apex, Salesforce Flow, or Process Builder when the stage of the opportunity is changed to "Won". An external service listens to the platform event channel using CometD (or a MuleSoft connector) and creates the appropriate records in the external system.

**Salesforce Connect/External Objects (with custom Apex adapters)** A solution based on Salesforce Connect/External Objects is not perfectly suited for a use case that purely requires data synchronization. However, this solution can apply in cases where users within Salesforce need to see, and potentially interact with data from the external system, and the data cannot be replicated in Salesforce. If the ERP or order management system does not support OData or GraphQL protocols, then the development team can use the [Apex Connector Framework](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) to write Apex classes that handle communication with the external system via a supported protocol.

**Data 360** A solution based on Data 360 is perfectly suited for use cases where we need harmonized data from different sources in one data store. It can be also used when we need to replicate data from one Salesforce org to multiple Salesforce orgs or to other external systems using Data 360 as a data hub. When an opportunity is won and updated in the source org, opportunity data will be synced to Data 360, where it can be replicated in other systems including Salesforce orgs using different mechanisms like actions, activations, and APIs. Similarly, an opportunity can be referred without replicating the data in other Salesforce orgs using Data Cloud One. However, Data Cloud One does not support non-Salesforce platforms.

### Pro-Code Tools for Outbound Integrations from Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Licensing</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>When to Use</strong></th>
            <th><strong>Additional License</strong></th>
            <th><strong>Sync (Request/Reply) or Async (Fire/Forget)</strong></th>
            <th><strong>Multi-Object Support</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Testing & Deployment**</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Built-In Error Handling/Retry Behavior</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong></th>
            <th><strong>Authentication Protocol</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Custom Apex</strong></td>
            <td>When you need more functionality than is available in low-code tools.</td>
            <td>Not Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes*</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>External Services</strong></td>
            <td>Integrating from code with external system APIs are described using OpenAPI specifications.</td>
            <td>Not Required</td>
            <td>Sync</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td>N/A</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>When you need a single enterprise-grade, unified solution to build, orchestrate, and manage your integrations; when you need to replace a legacy point-to-point architecture; or when you need API management support.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes*</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*Enabling Shield Platform Encryption changes certain behaviors, see [General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) for more details.

\*\*Testing and Deployment refers to the ability to build in a lower environment and deploy via the [Metadata API](https://developer.salesforce.com/docs/metadata-coverage/), packages, or change sets to production.

### Use Case: Outbound Integration Using Pro-Code Tools

> When opportunities are won, an order for the associated products needs to be created in the company’s ERP or order management system.

**Custom Apex** You can create an Apex trigger and trigger handler(s) on the Opportunity that makes a callout to the ERP or order management system when the stage of the opportunity is changed to "Won". Note that if you make callouts from a trigger or after performing a DML operation, you must use a method annotated as future or queueable. A callout in a trigger holds the database connection open for the lifetime of the callout. All Apex code is bound by [Apex Governor and API Limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm), which are revised on an ongoing basis.

**External Services** If the company’s external ERP or order management system are defined via an OpenAPI specification the callouts to those services that are performed in the future method or queueable job could be simplified. The registered external services can be called directly from Apex without needing to write boilerplate code. In the example, the callout to create the order can be handled by the external service.

**MuleSoft Anypoint** MuleSoft Anypoint provides enterprise-grade API management. MuleSoft Anypoint can create APIs to enable read (and/or write) access to data for Salesforce and many other enterprise systems. There are [many prebuilt connectors available](https://www.mulesoft.com/platform/cloud-connectors) to simplify implementation, and companies can create and publish their own connectors as well. These APIs can be deployed in Anypoint with flexible security policies, supporting centralized management and governance. There are no restrictions on volume of transactions, as long as the API has been properly sized for its peak utilization (as measured in vCores).

## External Systems Data to Salesforce (Inbound Integration)

For inbound integrations to Salesforce, you may consider different types of tools: low-code, pro-code, or a hybrid. The following sections provide guidance for each of these tool types and offer sample solutions.

- [Low-Code Tools for Inbound Integrations](#low-code-tools-for-inbound-integrations-to-salesforce)
- [Hybrid Tools for Inbound Integrations](#hybrid-tools-for-inbound-integrations-to-salesforce)
- [Pro-Code Tools for Inbound Integrations](#pro-code-tools-for-inbound-integrations-to-salesforce)

### Low-Code Tools for Inbound Integrations to Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Licensing</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>When to Use</th>
            <th>Additional License</th>
            <th>Sync (Request/Reply) or Async (Fire/Forget)</th>
            <th>Multi-Object Support</th>
            <th>LDV/Bulk</th>
            <th>Testing & Deployment*</th>
            <th>Debugging</th>
            <th>Built-In Error Handling/Retry Behavior</th>
            <th>Can Use with Data Encrypted at Rest</th>
            <th>Authentication Protocol</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>When you want to extend your data with bidirectional sync to enable mobile and other apps on Heroku, and you want the data to also be replicated to Salesforce.</td>
            <td>Required</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes, via Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>OmniStudio Integration Procedure</strong></td>
            <td>When you need to import and transform data from third-party sources without user interaction.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Declarative support</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>Named Credentials</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/External Objects</strong></td>
            <td>When you want data to appear in the Salesforce UI, but want the data to be stored in an external system that can use standard protocols like OData or GraphQL.</td>
            <td>Required</td>
            <td>Sync</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td>N/A</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*Testing and Deployment refers to the ability to build in a lower environment and deploy via the [Metadata API](https://developer.salesforce.com/docs/metadata-coverage/), packages, or change sets to production.

### Use Case: Inbound Integration Using Low-Code Tools

> A contact is updated in the organization’s ERP system. This contact information needs to be updated in Salesforce.

**Heroku Connect** Heroku Connect is typically used to keep a Heroku Postgres Database and Salesforce in sync. Unless the ERP system uses Heroku Postgres as its transaction store, this use case is not possible. If it does use Heroku Postgres, then changes made in the Postgres tables can be synced to objects in Salesforce using Heroku Connect.

**OmniStudio Integration Procedure** After the ERP system updates the contact record, an OmniStudio Integration Procedure with a Data Mapper Load Action and a Response Action can be called via the REST API generated by Data Mapper. First, a Data Mapper Load action sends a JSON or XML payload, which is used to upsert the contact records based on an External ID field or through an [Upsert Key](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio). If a simple response in JSON is all that is expected, a Response Action can send back any relevant information from the previous actions to indicate success or failure. If the ERP system expects a specific response then a Data Mapper Transform or Extract Action can be used to generate a JSON or XML response with additional features to declaratively include data that was generated in triggers by the contact record update. The main challenge with this scenario is concurrency: Multiple calls to update the same contact record concurrently will cause issues as the API exists directly in Salesforce.

**Salesforce Connect / External Objects** Salesforce Connect and external objects are not recommended for this use case, because the scenario specifically requires data replication in Salesforce. If you have a pre-existing Salesforce Connect integration built to the ERP, you can configure the OData 4.0 connector to support external change data capture if the ERP can support change data capture. Further, you must configure in Salesforce to subscribe to the change stream from the ERP, using Pub/Sub API.

### Hybrid Tools for Inbound Integrations to Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Licensing</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>When to Use</th>
            <th>Additional License</th>
            <th>Sync (Request/Reply) or Async (Fire/Forget)</th>
            <th>Multi-Object Support</th>
            <th>LDV/Bulk</th>
            <th>Testing & Deployment**</th>
            <th>Debugging</th>
            <th>Built-In Error Handling/Retry Behavior</th>
            <th>Can Use with Data Encrypted at Rest</th>
            <th>Authentication Protocol</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Platform Events</strong></td>
            <td>When you need a custom-defined, structured payload for near real-time changes in Salesforce or an external system.</td>
            <td>Not Required*</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/External Objects (with custom Apex adapters)</strong></td>
            <td>When you need data to appear in the Salesforce UI, but want the data to be stored in an external system that cannot use OData 2.0/4.0 protocols.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td>N/A</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>When you want harmonized data from different sources in one data store, or you want to replicate your data from other Salesforce orgs or to other external systems. Data 360 also supports virtualization for some platforms.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*[Add-on](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) required for high-volume use cases.

\*\*Testing and Deployment refers to the ability to build in a lower environment and deploy via the [Metadata API](https://developer.salesforce.com/docs/metadata-coverage/), packages, or change sets to production.

### Use Case: Inbound Integration Using Hybrid Tools

> A contact is updated in the organization’s ERP system. This contact information needs to be updated in Salesforce.

**Platform Events** Custom code in an external system publishes a Platform Event when the contact record is updated in the ERP. A trigger, Process or Flow in Salesforce can subscribe to the platform event, and update the corresponding Salesforce object(s) when an event is processed. The Platform Event may function simply as a signal that a change happened in the customer’s ERP system without containing any data, or it may contain the actual data needed to update the Salesforce object.

**Salesforce Connect/External Objects (with custom Apex adapters)** This solution isn't applicable in a use case that requires data replication. This solution is applicable if you need users in Salesforce to see information from an external system that must not or cannot be replicated in Salesforce, and the external system cannot support standard protocols like OData or GraphQL. See [Use Case: Outbound Integration Using Hybrid Tools](#use-case-outbound-integration-using-hybrid-tools) for an example use case for an Apex custom adapter.

**Data 360** When a contact is updated in external systems like ERP, the contact updates can be synced to Data 360 either using available out of the box connectors or using APIs and pro-code tools like MuleSoft. Contact can also be referenced in Data 360 using zero copy mechanism (available with some platforms). Once data is available in Data 360, different out of the box integration mechanisms can be used for syncing the data to other Salesforce orgs. Data can be accessed by reference using Data Cloud One. Data can be replicated too using activations and other APIs using out of the box connectors or with the help of pro-code tools like MuleSoft Anypoint platform.

### Pro-Code Tools for Inbound Integrations to Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Licensing</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>When to Use</th>
            <th>Additional License</th>
            <th>Sync (Request/Reply) or Async (Fire/Forget)</th>
            <th>Multi-Object Support</th>
            <th>LDV/Bulk</th>
            <th>Testing & Deployment****</th>
            <th>Debugging</th>
            <th>Built-In Error Handling/Retry Behavior</th>
            <th>Can Use with Data Encrypted at Rest</th>
            <th>Authentication Protocol</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Custom Apex REST & SOAP Web Services</strong></td>
            <td>When you need more functionality than provided by the native API endpoints such as cross object processing or other complex logic.</td>
            <td>Not Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes***</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>When you need a single enterprise-grade, unified solution to build, orchestrate, and manage your integrations; when you need to replace a legacy point-to-point architecture; or when you need API management support.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes***</td>
            <td>Multiple</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce APIs</strong></td>
            <td>When you need more control or have a pro-code skill set to build integrations via REST API, SOAP API, Bulk API, or GraphQL APIs, or gRPC.</td>
            <td>Not Required*</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes*****</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes**</td>
            <td class="guide-table-ok">Yes***</td>
            <td>Multiple</td>
        </tr>
    </tbody>
</table>

\*[API Request Limits and Allocations](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) apply.

\*\*Bulk APIs have aspects of retry behavior and a number of APIs offer _rollback_ protection via allOrNone setting (for example, see [allOrNone Parameters in Composite and Collections Requests](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm))

\*\*\*Enabling Shield Platform Encryption changes certain behaviors, see [General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) for more details.

\*\*\*\*Testing and Deployment refers to the ability to build in a lower environment and deploy via the [Metadata API](https://developer.salesforce.com/docs/metadata-coverage/), packages, or change sets to production.

\*\*\*\*\*Composite APIs have multi-object support.

### Use Case: Inbound Integration Using Pro-Code Tools

> A contact is updated in the organization’s ERP system. This contact information needs to be updated in Salesforce.

**Custom Apex REST and SOAP Web Services** You can create a web service using Apex code that could perform CRUD (create, read, update, delete) operations on the Contact object. This service will be invoked via SOAP or REST from the external system (the ERP).

**MuleSoft Anypoint** The intent of MuleSoft Anypoint is to provide enterprise grade API management. MuleSoft Anypoint offers a [large set of prebuilt connectors](https://www.mulesoft.com/platform/cloud-connectors) that you can use to integrate with many ERP systems including SAP, Oracle EBS, Oracle ERP, and NetSuite. You can create a flow to listen for events in these ERP systems (in this case, when a new contact is created). When the flow is kicked off it uses the Salesforce connector to create a new Contact record (or update one if the contact already exists). Additionally, it is possible to integrate with other systems, if the replication transaction involves syndicating the contact into other systems. If needed, you can use the mapping and transformation language (DataWeave) to perform complex logic and calculations as information flows across multiple disparate systems. Authentication against these systems can be done through many different authentication mechanisms such as Basic Authentication and OAuth, among others. There are no restrictions on volume of transactions as long as the flow has been properly sized for its peak utilization (measured in vCores).

**Native Salesforce APIs** As (or immediately after) the update transaction in the ERP system completes, you can perform an upsert operation on the Contact object via the SOAP API or perform a [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) against the Contact sObjects REST API in the Salesforce organization.

## Salesforce to Salesforce Integrations

The Salesforce to Salesforce product has reached its end of life. Salesforce to Salesforce made it easy for partners working together to sell to and support joint customers, but Salesforce will be investing in bringing more innovation to other tools. Moving forward, the following approaches are recommended for sharing data between Salesforce organizations.

### Tools for Data Integration Across Salesforce Organizations

<table>
    <thead>
        <tr>
            <th></th>
            <th>Guidance</th>
            <th>Cost</th>
            <th>Timing</th>
            <th>Volume & Scale</th>
            <th></th>
            <th></th>
            <th>Delivery & Maintenance</th>
            <th></th>
            <th>Privacy & Security</th>
            <th></th>
            <th>Tools to Implement</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>When to Use</strong></th>
            <th><strong>Additional License</strong></th>
            <th><strong>Sync (Request/Reply) or Async (Fire/Forget)</strong></th>
            <th><strong>Multi-Object Support</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Testing & Deployment*</strong></th>
            <th><strong>Debugging</strong></th>
            <th><strong>Built-In Error Handling/Retry Behavior</strong></th>
            <th><strong>Can Use with Data Encrypted at Rest</strong></th>
            <th><strong>Authentication Protocol</strong></th>
            <th><strong>Low Code → Pro Code</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>When you want to extend your data with bidirectional sync across Salesforce orgs and also enable access to the data from mobile and other apps running on Heroku</td>
            <td>Required</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>No</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes, via Shield Connect</td>
            <td>OAuth</td>
            <td>Low Code</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>When you need a single enterprise-grade, unified solution to build, orchestrate, and manage your integrations; when you need to replace a legacy point-to-point architecture; or when you need API management support</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes**</td>
            <td>Multiple</td>
            <td>Pro Code</td>
        </tr>
        <tr>
            <td><strong>Native Salesforce APIs</strong></td>
            <td>When Salesforce or Heroku Connect are not an option or you need more complex processing</td>
            <td>Not Required</td>
            <td>Both</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>No</td>
            <td class="guide-table-ok">Yes**</td>
            <td>Multiple</td>
            <td>Pro Code</td>
        </tr>
        <tr>
            <td><strong>Change Data Capture</strong></td>
            <td>When you need to publish record-level changes made in Salesforce to an external system and don't need a custom payload.</td>
            <td>Required</td>
            <td>Async</td>
            <td>No</td>
            <td>No</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect with Cross-Org Adapter</strong></td>
            <td>When you want users in one org to view or edit records in a different org without data replication</td>
            <td>Required</td>
            <td>Async</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td>N/A</td>
            <td>N/A</td>
            <td>Multiple</td>
            <td>Low Code</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>When you want users in one org to view or edit records in a different org with data replicated in Data 360.</td>
            <td>Required</td>
            <td>Both</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>With pro-code tools</td>
            <td class="guide-table-ok">Yes</td>
            <td class="guide-table-ok">Yes</td>
            <td>Multiple</td>
            <td>Hybrid</td>
        </tr>
    </tbody>
</table>

\*Testing and Deployment refers to the ability to build in a lower environment and deploy via the [Metadata API](https://developer.salesforce.com/docs/metadata-coverage/), packages, or change sets to production

\*\*Enabling Shield Platform Encryption changes certain behaviors, see [General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) for more details.

_Platform events are not optimal for integrating data from one Salesforce organization to another, because they can’t “listen” between organizations for the same event. Custom Apex is also not a recommended approach for this type of integration._

### Use Case: Connecting Multiple Salesforce Orgs

> A large enterprise operates across multiple business units (BUs). Each BU has its own Salesforce organization. A single customer deals with multiple business units of the enterprise and thus has account and opportunity data in multiple organizations. The enterprise needs to access an aggregated view of all the Account and Opportunity data across all BUs in a single org.

_Note: All solutions below design for the least amount of data replication, in accordance with [Takeaway #1](#takeaways)._

**Data 360** Account and opportunity data from different Salesforce orgs can be ingested into Data 360 using out of the box Salesforce connectors. They can be aggregated and harmonized as well (if required). Once data is aggregated in Data 360, it can be accessed in other Salesforce orgs using Data Cloud One without data replication.

**Heroku Connect** For each BU's individual organization, you can use Heroku Connect to sync changes from Salesforce into a single Heroku Postgres database. In this scenario, bi-directional syncing isn't enabled, only syncing from Salesforce to Postgres. Then, in Heroku Connect, you can enable the OData provider and select the tables you want to expose as external objects in the Salesforce org where you want an aggregated view. From within Salesforce, you define an external data source pointing to the OData provider in Heroku.

**MuleSoft Anypoint** MuleSoft Anypoint provides enterprise-grade API management. A MuleSoft Anypoint API can be configured so that it reads information from multiple related Salesforce organizations using the Salesforce connector with multiple connections to the organizations. The MuleSoft flow can query the different Salesforce organizations and return a specific structure that is enhanced or enriched with other third-party information if needed. When the API is invoked, it will make all the proper Salesforce organization callouts (in this example querying Account and Opportunity information) so that the data can be processed by the consumer (likely a UI). Authentication against these systems can be done through a variety of authentication mechanisms including basic authentication and OAuth. There are no restrictions on the volume of transactions, so long as the flow has been properly sized for its peak utilization (measured in vCores or Cores).

**Native Salesforce APIs** Query operations can be issued to each of the organizations of interest, notably via the Salesforce Bulk API 2.0, which is well-suited to efficiently extract thousands of records. You can retrieve the query results from each organization individually and aggregate them with a custom application or middleware per customer requirements.

**Salesforce Connect with Cross-Org Adapter** The Salesforce Connect Cross-Org adapter is not a strong fit in this scenario, since Accounts or Opportunities from remote orgs will all appear in the central org as _different_ objects. For example, there is no way to add up a grand total for the Amounts of all the Opportunities across all the orgs.

**Selective Updates Cross-Org Scenario:** A salesperson, using Salesforce organization A, needs to view and update Case data from Salesforce organization B and add case comments to the parent case on Salesforce organization B while working in organization A. Data must not be replicated to organization A.

**Heroku Connect** You can use the same approach described in the _Data Aggregation Scenario_ above. However, you must enable CRUD on the external object via the OData connector and write the changes back to Heroku Postgres.

**MuleSoft Anypoint** MuleSoft Anypoint provides enterprise-grade API management. You can use the same approach described in the _Data Aggregation Scenario_ above.

**Native Salesforce APIs** Use Named Credentials and invoke the native Salesforce APIs to read and update data in the related Salesforce organization. A component must be designed to display the data.

**Salesforce Connect with Cross-Org Adapter** The ability to view data in an external object (as well as edit the data if you have CRUD enabled on the external object) is supported through the [Salesforce cross-org adapter](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5). Relationships are also supported between external objects so you can link to the parent case in the external object. However, creating relationships is a manual process today in which you convert an existing datatype to a relationship datatype. Additionally, optimizations made within Service Cloud to work with Cases more effectively do not cascade through to the remote org. Salesforce strongly recommends testing the Cross-Org Adapter and evaluating the tradeoffs in working with External Objects vs Standard Objects for your use case.

**Data Synchronization Cross-Org**: When an account for a customer is updated in one of the organization’s business unit Salesforce organizations, the other Salesforce organization Account objects need to be updated to keep consistent account information.

**Data 360** Data 360 can be used for data replication from one org to another Salesforce org. Account data from one Salesforce org can be ingested to Data 360 using out of the box Salesforce connectors. We can use data activation mechanisms like batch activation, near real time data actions or API based activations as well to move the data from Data 360 to Salesforce Org.

**Heroku Connect** You can use the same approach described in the _Data Aggregation Scenario_ above. However, you must enable bidirectional syncing, and you no longer need to enable Salesforce Connect as the bi-directional syncing will keep all the organizations up-to-date when changes are made to the Postgres table.

**MuleSoft Anypoint** MuleSoft Anypoint provides enterprise-grade API management. You can [configure a Mule application](https://docs.mulesoft.com/design-center/about-designing-a-mule-application) with Flow Designer in MuleSoft Anypoint to listen for standard and custom object events to kick off an autolaunched flow in Salesforce. When the Mule application is triggered, it can invoke the Anypoint Connector for Salesforce to communicate with any number of Salesforce organizations. In this use case, when an Account record is updated in one Salesforce organization, the Mule app can update Account records in the related Salesforce organizations. Each related Salesforce organization would have a unique update step built into the overall application flow in MuleSoft. Authentication against these systems can be done through various authentication mechanisms, including basic authentication and OAuth. There are no restrictions on the volume of transactions as long as the flow has been properly sized for its peak utilization (measured in vCores or Cores).

**Native Salesforce APIs** The [Replication API](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (getUpdated, getDeleted operations) could be used to sync data across orgs, but this approach is not recommended.

**Salesforce Connect with Cross-Org Adapter** You can use record-triggered flows and external objects to keep some data in sync between Salesforce organizations. For example, updating an account record in Organization A triggers a flow that then updates the matching record on the Account external object, which writes those updates to the account record in Organization B. This requires the proper use of flow semantics to avoid [mixed DML transactions](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1). Also, bear in mind that Validation Rules and Flows in Organization B will be triggered in the same way as when changes are made by our REST/SOAP APIs.

## Closing Remarks

Keep this guide in mind and refer to it when you’re planning a new data integration involving Salesforce. It’s always a good idea to understand the full scope of options available to you, and how they may fit with your specific use case.

### Tell us what you think

Help us make sure we're publishing what’s most relevant to you. [Take our survey](https://sfdc.co/J0cWb) to provide feedback on this content and tell us what you’d like to see next.

<!-- document id=6c8d6f15a2cab3b43764dfa2d34b3aebeb5b5a16be6b1304edaf5046787f4df5 url=/architect/next/en-us/decision-guides/guides/determining-agentic-vs-traditional-workflow-automation.md -->

# Determining Agentic and Traditional Workflow Automation

With Agentforce, enterprises can now unlock new paradigms for automated work that can’t easily be reduced to rules. These new capabilities include resolving customer intent from unstructured conversations, coordinating multi-party processes across systems, and responding to operational conditions in real time. Agentic workflows use automation designed to reason toward outcomes rather than execute predefined steps. Meeting this demand requires a platform that operates across the full spectrum of automation complexity, and a framework showing where each capability fits.

Agentforce combines the Einstein Trust Layer, Reasoning Engine, Agent Script, Flow, Apex, and Data 360 into a single, unified platform. This combination handles everything from simple record trigger automation to complex multi-agent orchestration across voice, vision, documents, and real-time telemetry. MuleSoft extends this platform with the MuleSoft fabric, governance, and cross-system orchestration needed to connect agentic workflows across an enterprise. Agentforce Operations (previously Agentforce Supply Chain) applies these capabilities to the specific demands of operational and manufacturing processes.

## Guide Overview

This guide introduces the Orchestration Density framework and guidelines for making informed decisions across this product landscape. The framework provides architects with a repeatable approach to select the right tools and patterns using density levels for intelligent automation use cases on the Salesforce Platform.

## Products in Scope

| Product               | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agentforce            | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) is Salesforce's platform for building and deploying AI agents. It uses the Atlas engine to trigger real-time, dynamically grounded actions through Apex, and Data 360.                                                                                                                                                                                                                                                                                                                           |
| Agent Script          | [Agent Script](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) is a declarative domain-specific language (DSL) used in Agentforce Builder to define workflows, business rules, and conversational logic for agents                                                                                                                                                                                                                                                                                                                                         |
| Agentforce Grid       | [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) is an AI-native, no-code spreadsheet-like interface for rapidly designing and operationalizing AI workflows at scale.                                                                                                                                                                                                                                                                                                                                                                     |
| Agentforce Operations | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (previously Agentforce Supply Chain) is an AI-powered collaborative workflow management orchestration platform designed to streamline and automate back office business processes.                                                                                                                                                                                                                                                                           |
| MuleSoft              | [MuleSoft](/docs/architect/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) is a comprehensive, unified, and open platform for enterprise integration and agentic governance. Through API-led connectivity and MuleSoft Agent Fabric and Agent Broker, it serves as the integration fabric, governance layer, and cross-system orchestration foundation for connecting agentic workflows across the enterprise                                                                                                                                                         |
| Flows and Apex        | [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) is a powerful, point-and-click automation tool for building complex business processes visually without code. [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) is a proprietary, object-oriented programming language for the Salesforce platform, similar to Java. It’sused to build custom business logic, automate processes, and extend core CRM functionalities beyond declarative tools. |

## Takeaways

Agentforce represents a fundamental shift in how work gets done on the Salesforce Platform, from rules-based automation to reasoning-based workflows. To unlock its potential, architects must make deliberate, informed decisions about where agents fit, how they are composed, and what they orchestrate. The following principles provide a repeatable guideline for agentic decisions.

- **Use the right tool for the right task.** Use orchestration density based on execution path, modality mix, and goal complexity to determine the best fit solution.

  - Use **Traditional Automation** with Flows and Apex for rule-based deterministic work, where the outcome can be entirely scoped and defined by a set of rules. Traditional automation results in a static execution path, which guarantees predictable and repeatable outcomes and is crucial for auditability. Choose traditional automation for tasks that demand strict compliance and legal adherence.

  - Use **Agentforce Grid** for bulk inference use cases with low to medium orchestration complexity. This pattern uses single-turn generative reasoning to classify, score, or summarize data across a high volume of CRM records, ensuring high-throughput execution with immediate auditability.

  - Use **Agentforce with Agent Script** for tasks that have open-ended goals where the desired outcome is known, but the exact execution path can’t be specified at design time. Apply this pattern to requirements that require reasoning via guided determinism, to ensure predictable and traceable outcomes.

  - Use **Agentforce Operations** to streamline and automate collaborative business processes with AI-enabled management for supply chain workflows.

- **Avoid applying agentic workflows to low-orchestration-density use cases**. Evaluate tradeoffs between traditional and agentic automation for functional and non-functional requirements. Traditional automation can offer the scale, reliability, and performance required for your use case.

- **Adopt an Agent Automation Hybrid approach**, which combines Agentforce and traditional automation with Flows and Apex, when this synergy offers greater value than using either agentic or traditional automation in isolation.

## Decision Points

The Salesforce sObject is traditionally the primary entry point for record automation. The system executes logic based on rules, beginning immediately after a Data Manipulation Language (DML) event such as insert, update, or delete. To decide between tools for efficient [record-triggered automation](/docs/architect/decision-guides/guide/record-triggered.html), we introduced [Automation Density](/docs/architect/decision-guides/guide/record-triggered#automation-density.html) as a means to measure the complexity of the system, considering automation quantity, record volume, and dependency sprawl. Traditional automation is limited by the extensive pre-work required to bring data into a structured, schema-compliant, and rules-based construct.

Agentic automation upgrades traditional automation using user intent or unstructured data as the input where reasoning can be applied to reach a desired outcome. Architects must decide when to leverage probabilistic reasoning for multi-modal unstructured data and when to enforce guided, deterministic workflows to mitigate the risk of unpredictable outcomes.

When the requirement shifts from executing rules-based steps to reasoning toward outcomes, architects need a standardized framework to evaluate the reasoning depth and goal complexity of the proposed solution.

### Orchestration Density

Orchestration density is the measure of complexity within an agentic workflow. Three factors determine orchestration density: execution path, goal complexity and modality mix. While automation density measures the physical complexity of the system’s rules and volume, orchestration density measures the reasoning complexity of the agent's path toward a goal. Use the composite orchestration density to evaluate your design requirements and map to the architectural standard.

- **Execution Path**: The degree to which workflow can be fully scoped and specified at design time. A fully specified workflow means the workflow defines every branch and outcome resulting in a predetermined execution path. A non-specifiable workflow has a path that can emerge during runtime through reasoning against contextual data and instructions.
- **Goal Complexity**: The number of distinct outcomes, decision points, and path variations that the workflow must resolve at runtime. A low-complexity workflow handles a single contained task with a predetermined outcome, while a high-complexity goal spans multiple stages with competing or conflicting goals with edge cases that can’t be anticipated at design time.
- **Modality Mix**: The range of input types a workflow must process, and the output forms it must produce. A low modality mix reads standard CRM fields and produces record updates. A medium modality consumes a mix of structured CRM fields and static, unstructured data, like email bodies or case transcripts, to produce record updates. A high modality mix consumes dynamic, real-time streams, like live audio or telemetry, and produces multi-modal outputs across multiple external systems.

![Orchestration Density framework diagram showing execution path, goal complexity, and modality mix axes](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png)

### Factor Sequencing

Determining the appropriate orchestration density level requires sequentially evaluating the execution path, goal complexity, and modality mix. Inspect the execution path first. If a path is fully specifiable, begin with traditional automation. Using an Agentic solution just to orchestrate and execute a deterministic path without any reasoning requirement is an anti-pattern. It leads to agent sprawl (excessive, unmanaged AI agent proliferation) and agent slop (low-quality, unnecessary AI-generated output), resulting in poor value returns.

For partial or non-specifiable paths, continue evaluating goal complexity. If the goal complexity is well-defined but certain nodes along the path need probabilistic evaluations, consider calling agents from Flow or Apex to meet the specific localized need. Instead, if the steps in the execution path need one or more AI-driven requirements across a large set of records, consider Agentforce Grid. Grid supports multi-step, sheet-based workflows through multiple AI or agent columns. It is best suited for bulk, row-oriented execution. This approach ensures that the workflow remains highly performant and auditable, invoking probabilistic reasoning only where the path cannot be predefined.

As goal complexity increases with competing dimensions (for example, determining an insurance claim payout along with fraud detection, compliance with policies, and customer satisfaction) and non-specifiable execution paths, consider Agentforce with Agent Script for guided determinism in your automation. For cross-enterprise use cases that involve Salesforce and third-party systems, use MuleSoft Fabric and Agent Broker.

Finally, evaluate the modality mix to identify the necessary technical capabilities, such as multi-modal connection or specialized integration. Modality mix functions as a capability selector, not a density calculator. It helps determine the infrastructure required to handle the input and output shape of the solution, without altering its fundamental orchestration logic.

### The Density Selection Matrix

Use this matrix to determine the architectural standard for your agentic automation. Balance traditional and agentic automation by selecting the approach that solves your automation problem.

- **Traditional Automation (Low orchestration density):** Use traditional automation when the process is triggered by a record change, the data is structured, logic is rule-based and pre-determined, and the outcome must be predictable (for example, standard price calculations or auto-task creation).
- **Agentforce Grid (Low to medium orchestration density):** Use Agentforce Grid when bulk AI tasks across existing records must be processed (for example, summarize the last 50 cases for every Account in this list, calculate the sentiment score and persist the score in the case field).
- **Hybrid Orchestration (High-Order Augmented Automation):** Use hybrid orchestration when automating a complex end-to-end business process (for example, claims processing or onboarding) that requires the planning capabilities of AI but the transaction integrity of Flow and Apex.
- **Agentforce Agent Script (High Intent Complexity):** Use Agent Script when the entry point is unstructured (for example, chat, email, and voice) and the resolution requires a conversation or the ability to handle ambiguous user requests.

| Density Level     | Execution Path                                                                                                     | Goal Complexity                                                                               | Modality Mix                                                                                                                | Architectural Standard                                                                                                                                          |
| :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Low**           | Fully specifiable                                                                                                  | **Low:** Single contained task with pre-defined outcomes.                                     | **Single Modality:** Reads and writes structured Salesforce Object records.                                                 | Record-Triggered Automation. If the use case has at least one reasoning task, use Agentic Actions in the workflow.                                              |
| **Low \- Medium** | Fully or partially specifiable                                                                                     | **Low:** Series of steps with pre-defined outcomes.                                           | **Mixed Modalities:** Input or output can have a mix of structured and unstructured data.                                   | Use Agentforce Grid Batch Inferences for bulk tasks across existing records with agentic action.                                                                |
| **Medium**        | Fully or partially specifiable. The execution path is pre-defined but intermediate steps need reasoning.           | **Medium:** Series of Apex or Flow based steps with variable outcomes.                        | **Mixed Modalities:** Input or output can have a mix of low volume structured and unstructured data.                        | Hybrid (Agentforce \+ Apex/Flow): Use Agentforce for high density reasoning and planning, Agent Script for guided determinism, and Apex/Flow for orchestration. |
| **High**          | Partially or non-specifiable. The goal is pre-defined but intermediate steps need runtime context and user intent. | **High:** Multiple competing goals with heavy reasoning needs require deterministic outcomes. | **Mixed Modalities:** Input or output can have a mix of high volume structured and unstructured data arriving in real time. | Use Agent Script to balance deterministic control with reasoning. Use MuleSoft Agent Fabric for third party MCPs or A2A for complex multi-agent collaboration.  |

## Product Comparison

| Capability                     | Traditional Automation (Flow/Apex)                                                                                        | Agentforce Grid                                                                                                                               | Agentforce                                                                                                                             | Agentforce with Agent Script                                                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Logic Type & Determinism**   | **Deterministic:** Uses fixed if-then-else logic. The execution path is 100% predictable based on record state.           | **Mixed:** Deterministic via structured steps while individual AI steps can be probabilistic.                                                 | **Probabilistic:** Uses multi-turn reasoning to determine the best path toward a goal.                                                 | **Guided Determinism:** Uses reasoning to plan the path and allows execution on deterministic node paths.                                              |
| **Speed of Delivery**          | **Recommended (Flow):** Visual tools allow rapid building of record-triggered logic without code.                         | **Recommended for repetitive AI automation:** Fastest way to apply AI logic across existing record sets without building new flows.           | **Recommended:** For configuration of Subagents (previously Topics), Instructions, and Skill mapping for a specific domain or problem. | **Recommended:** For advanced mapping of state-based graphs and edge logic.                                                                            |
| **Input Modality**             | **Recommended for Structured Only:** Limited to CRM fields and related record collections.                                | **Recommended for Semi-Structured:** Processes bulk text (descriptions, transcripts) from record fields.                                      | **Recommended for Multi-modal:** Processes natural language, voice, and vision (unstructured data).                                    | **Recommended for High Density:** Synthesizes multi-modal inputs with real-time system state data.                                                     |
| **Reasoning Depth (Planning)** | **Not Available:** Logic is imperative; it cannot "think" or plan steps dynamically. However, data can be sent to agents. | **Low:** Single-step inference applied across a record set (batch AI).                                                                        | **Medium/High:** Uses reasoning loops (Reason-Act-Observe) to resolve complex intent.                                                  | **Governed:** Reasoning is restricted to navigating a pre-defined graph of business states.                                                            |
| **Modularity & Reusability**   | **Recommended:** Modular by default via subflows and Apex classes.                                                        | **Limited:** Logic is typically tied to the specific grid row. Column setups and templated workflows can be reused across the entire row set. | **Available:** Skills (Flows/Apex) are reused across different Subagents (previously Topics) and connected agents.                     | **Recommended:** Nodes in the Agent Graph are discrete, reusable functional units.                                                                     |
| **Transaction & DML Control**  | **Recommended (Apex):** Full control over Savepoints, rollbacks, and bulkification.                                       | **Available:** Each row is processed independently, so execution scope is per record.                                                         | **Limited:** Actions are executed as individual, decoupled steps in a session.                                                         | **Recommended:** Uses Flow/Apex nodes to serve as deterministic anchors for all DML. Distributed transaction control support across agents is limited. |
| **Ambiguity Handling**         | **Not Available:** Requires pre-defined paths. Unexpected input leads to failure or static errors.                        | **Limited:** Output quality depends on prompt grounding. The workflow cannot interactively ask for clarification.                             | **Recommended:** Handles "unknown" states by asking questions or selecting alternate skills.                                           | **Available:** Uses "Fallback Nodes" to manage reasoning failures or process timeouts.                                                                 |
| **Visibility & Governance**    | **Recommended:** Flow Trigger Explorer provides a visual map of all record-triggered logic.                               | **Available:** Grid-based UI provides clear visibility into row-level results and supports auditability of outputs.                           | **Available:** Monitoring Logs provide transparency into how the agent made decisions.                                                 | **Requires Expertise:** Requires monitoring both the Graph traversal and LLM inference logs.                                                           |
| **Performance & Scale**        | **Recommended** Optimized for high-volume synchronous record processing.                                                  | **Recommended** Efficiently processes bulk AI tasks across large data volumes.                                                                | **Latency-Sensitive** Dependent on inference time; unsuitable for high-density bulk updates.                                           | **Moderate** Suitable for complex long-horizon tasks, but has higher overhead.                                                                         |

## Use Cases

This table provides general best-fit recommendations for various use cases.

| Use Case                                                    | Description                                                                                                                                                                                                                                | Best-Fit                                                                                                                                                                                                                           | Rationale                                                                                                                                                                                                                                                                                                                                                                                           |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Record processing**                                       | Automation triggered by a DML event on a structured Salesforce object where every branch and outcome can be fully defined at design time.                                                                                                  | Use Record-Triggered flow. This is a low density traditional automation.                                                                                                                                                           | Low orchestration density. Single modality (structured CRM fields) and a single contained goal with a predictable, auditable execution path.                                                                                                                                                                                                                                                        |
| **Transactional control with complex logic**                | Automation requiring savepoints, rollbacks, partial commits, or bulk-safe data manipulation across high record volumes.                                                                                                                    | Use Apex for traditional, low-density deterministic automation.                                                                                                                                                                    | Low orchestration density. Apex provides full control over transaction integrity, deduplication of expensive computation, and platform-level caching \- capabilities not available in Flow.                                                                                                                                                                                                         |
| **Moderately complex logic within a structured process**    | Automation where the overall process is rule-based but individual steps require computation or data manipulation beyond declarative capability.                                                                                            | Use Flow with Invocable Apex for low-density deterministic logic.                                                                                                                                                                  | Low orchestration density. Flow acts as the orchestration layer; Invocable Apex encapsulates high-complexity operations as reusable, bulk-safe components.                                                                                                                                                                                                                                          |
| **Scheduled and temporal processing**                       | Automation that must execute at a dynamically calculated future date relative to a record event.                                                                                                                                           | Use Traditional automation (record-triggered flows) for low-density deterministic processing.                                                                                                                                      | Low orchestration density. [Flow scheduled paths](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5) provide automatic scheduling, cancellation, and rescheduling if record data changes \- not natively available in Apex triggers.                                                                                                            |
| **Bulk record inference**                                   | Applying a single AI reasoning step uniformly across a large set of existing records to generate a classification, summary, or score.                                                                                                      | Use Agentforce Grid for batch inference and to use repetitive agentic capabilities at scale.                                                                                                                                       | Medium orchestration density. Batch Inference with single modality at scale: the agent reads structured record fields and writes a uniform output back to each record. Low goal complexity with one repetitive inference pattern.                                                                                                                                                                   |
| **Unstructured input resolution**                           | Automation where the entry point is a natural language request, email, or conversation that must be interpreted, classified, and resolved through reasoning.                                                                               | Use Agentforce for medium-density, intent-driven, unstructured input resolution.                                                                                                                                                   | Medium orchestration density. Mixed modality: the agent consumes unstructured conversational input, then produces text responses or structured record updates. The goal requires resolving user intent across a bounded set of outcomes.                                                                                                                                                            |
| **Moderately complex logic within a probabilistic process** | Automation where the overall process is rule-based, but individual steps require AI capabilities like summary or RAG retrieval.                                                                                                            | Use Flow with Invocable Apex and Prompt Templates for low-density deterministic processes requiring AI capabilities.                                                                                                               | Medium orchestration density. Flow acts as the orchestration layer while [Prompt Templates](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api), [Agentforce Service agent, and Agentforce Employee agent](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) are exposed as Invocable actions. |
| **Guided process orchestration**                            | Automation spanning across multi-step workflows where one action's completion triggers additional actions                                                                                                                                  | Use [Agent Script with Actions](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining) for high-density, non-specified execution paths that require guided process orchestration. | High orchestration density \- mixed modality across input and output. Competing outcomes and edge cases that cannot be fully anticipated at design time. Agent Script provides guided determinism.                                                                                                                                                                                                  |
| **Cross-system process orchestration**                      | Automation coordinating a multi-step business process across multiple backend systems where no single system owns the end-to-end flow                                                                                                      | Use MuleSoft Process API with Agent Broker for medium to high-density cross-system process orchestration.                                                                                                                          | High orchestration density \- Process APIs encapsulate complex multi-step business logic so agents do not need to understand the orchestration behind operations like order processing or inventory checks. [Agent Broker](https://www.mulesoft.com/ai/agent-broker) dynamically sequences and invokes required agents and tools from a single natural language goal.                               |
| **Backend system abstraction**                              | Orchestration where agents must interface with legacy systems, databases, or third-party SaaS platforms lacking native Agentforce connectivity.                                                                                            | Use MuleSoft with the MCP Connector to wrap legacy systems and provide model context.                                                                                                                                              | Medium orchestration density. System APIs offer a secure, abstracted interface to systems of record, ensuring agentic workflows are decoupled from backend complexity. The MCP Connector transforms MuleSoft applications into MCP-compliant servers for immediate discoverability and invocation.                                                                                                  |
| **High-volume document processing and exception handling**  | Automation that reads, interprets, and reconciles inbound structured and semi-structured documents against existing records at scale \- handling variances, partial matches, and exceptions with appropriate manual intervention.          | Use Agentforce Operations for medium-density, intent-driven high-volume document processing.                                                                                                                                       | Medium orchestration density with semi-structured input modality. Goal complexity driven by matching rules, exception paths, and approval thresholds per document. Requires reasoning per record, not uniform single-turn inference.                                                                                                                                                                |
| **Multi-agent orchestration across vendors**                | Automation requires collaboration between specialised agents built on different platforms or vendors.                                                                                                                                      | Use MuleSoft with A2A Connector and Agent Fabric for multi-agent orchestration across different systems.                                                                                                                           | Medium to high orchestration density. The A2A Connector enables peer-to-peer multi-agent workflows with enterprise-grade governance and reliability, regardless of where each agent is built or hosted.                                                                                                                                                                                             |
| **Unstructured document to workflow conversion**            | Automation where operational processes defined in unstructured sources (SOPs, supplier rule documents, or process diagrams) must be converted into executable agentic workflows without manual coding.                                     | Use Agentforce Operations for high-density, emergent unstructured documents to workflow conversion.                                                                                                                                | High density with a high modality mix on input. Ingests PDFs, Word documents, and image-based diagrams. Goal complexity determined by the scope and branching of the ingested process. Execution path cannot be specified at design time.                                                                                                                                                           |
| **Multi-party orchestration**                               | Automation spanning the coordinated onboarding of external parties \- collecting required data, verifying compliance, managing approvals, and updating systems of record across many concurrent onboarding tracks.                         | Use Agentforce Operations for medium-to-high density, intent-driven to emergent multi-party orchestration.                                                                                                                         | Multiple interdependent verification and approval steps must resolve sequentially before onboarding completes. Modality mix includes structured records, unstructured documents, and external party communications.                                                                                                                                                                                 |
| **Predictive asset intervention**                           | Automation where a predictive engine ingests real-time telemetry to identify impending failure conditions and triggers a coordinated multi-step back-office response.                                                                      | Use Agentforce Operations and Agentforce for Manufacturing for high-density predictive asset intervention.                                                                                                                         | Data Cloud handles high-modality IoT telemetry and anomaly detection. Agentforce Operations then orchestrates the medium-modality back-office workflow—managing field service records, inventory data, and customer communications—resolving the process end-to-end.                                                                                                                                |
| **Large-scale supplier communication management**           | Automation managing ongoing structured and semi-structured communications across a large supplier base \- including order acknowledgements, delivery date changes, and exception notifications.                                            | Use Agentforce Operations for Batch Inferences to a medium density supplier communication management.                                                                                                                              | Where communications are uniform across suppliers, use Agentforce Grid for batch processing. Where responses require contextual reasoning per supplier relationship, escalate to medium density with Agentforce Operations.                                                                                                                                                                         |
| **Lead Management (High-Speed, Intelligent Routing)**       | Automation that ingests real-time marketing responses, uses AI scoring and Data Cloud enrichment for qualification, and uses flows for sub-minute, intelligent assignment and routing of high-quality leads to the appropriate sales team. | Use Traditional Automation (Flow) \+ Data Cloud and AI for medium-density high-speed intelligent lead routing.                                                                                                                     | Requires high speed (Speed to Lead \< 1 min) and complex, data-driven routing based on AI lead scoring, job level, and activity history. Uses Flows for fast, deterministic assignment logic, augmented by probabilistic AI and Data Cloud for lead qualification and enrichment.                                                                                                                   |
| **Lead Nurturing**                                          | Nurtures low-score leads until they are ready for a sales conversation.                                                                                                                                                                    | Use Lead Nurturing Agent for targeting and improving low-quality leads for medium to high density automation.                                                                                                                      | Sends personalized, multi-touch emails grounded with lead data and customer success stories. It handles email responses and uses Flow for handoff.                                                                                                                                                                                                                                                  |
| **Inbound Lead Qualification**                              | Qualifies and nurtures higher-score inbound leads autonomously.                                                                                                                                                                            | Use Lead Nurturing Agent to qualify and engage leads.                                                                                                                                                                              | Executes multi-touch email outbound, meeting booking, product Q\&A, and objection handling. It can operate in a "send as seller" mode, sending emails through the assigned lead owner.                                                                                                                                                                                                              |

## Use Case Mapping

![Use case mapping diagram showing various automation scenarios across orchestration density levels](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png)

## Non-Functional Considerations

**Latency**

Synchronous record-triggered flows execute within the platform transaction and complete in milliseconds. Agentforce inference time is dependent on the Atlas Reasoning Engine and scales with reasoning depth and modality complexity. Agentforce is unsuitable for high-volume, synchronous record processing where latency is a primary constraint.

**Cost**

The reasoning cost of an agentic workflow must be justified against the business value of the outcome. For high-volume, low-orchestration density tasks where a deterministic path exists, traditional automation or Agentforce Grid might be more economical than an end-to-end agentic workflow. Ensure the design accommodates the right retry pattern with explicit max-retry limits and breakers. This guardrail limits the compounding cost-overrun risk associated with bulk processing.

**Governor Limits**

Evaluate high-volume agentic workflows against daily platform limits for asynchronous execution. Agentforce Grid batch operations follow standard platform transaction limits. For automation involving Salesforce Objects, consider the total daily number of DML operations, as Salesforce enforces both shared resource management in a multitenant environment, and [governor limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150) to prevent runaway automations from monopolizing shared resources.

**Auditability and Compliance**

Traditional automation produces fully auditable execution trails through Flow Trigger Explorer and Apex logs. Agentforce-based end-to-end or hybrid patterns produce reasoning logs that provide transparency into agent decision making, but they require expertise to interpret. Guided determinism via Agent Script is the recommended pattern for regulated industries where full execution auditability is a compliance requirement.

**Escalation**

Agentic workflows operating at high density should incorporate explicit human approval or escalation gates for actions with irreversible consequences, such as financial transactions, regulatory submissions, or supplier commitments. Agent Script conditional controls provide the mechanism for enforcing these gates deterministically within an otherwise agentic workflow.

## Related Best Practices

**Prioritize simplicity in your orchestration design**. Start at the minimal orchestration level that can achieve the goal, validate it under real load, and iterate. Every additional agent, handoff or dependency in your chain introduces a new surface that can produce inconsistent behavior.

In your specifiable execution path, at nodes where reasoning is required, begin embedding an agent. Follow the best practices for building Agents in Agentforce. Avoid packing numerous subagents (previously “topics”) and never bloat instructions. Agents deployed in automation use cases can afford to be lean, as they are not the only interface. Choose the right primitive for chaining. An orchestration (delegation) pattern has tighter control over the execution sequence and can delegate sub-tasks to specialists. Avoid choreographed (handoff) patterns. If you must implement a handoff design, provide the receiving agent with the goal, context and state so that it can optimize globally rather than local objectives.

**Avoid actions or tools sprawl**. Actions are where agent reasoning is realized, and their design determines whether they produce reliable outcomes or failures. Every action must return a structured, observable response that the AI agent can use to plan the next turn of the conversation.

Having more than one action (and different output constructs) to do the same task degrades the agent’s ability to reason or pick the right tool for the job. It may cause the agent to miss nuances. Overlapping action definitions risks wrong classification. Make sure your action library is audited, versioned and conforms to Subagent (previously Topic) scope.

**Define observable goals.** Define the goal as an observable outcome, not just a procedure. A vague goal invites agent drift. Augment with a specifiable execution path. Use Agent Graph with hybrid reasoning to model the goal as a graph node with explicit state. The runtime tracks the agent’s current position in the workflow and restores it after tangential inputs; it won’t lose the goal when it receives additional information in the context window.

**Test and evaluate**. Implement a robust testing and evaluation framework to validate the reasoning of probabilistic nodes and the output of agentic automations. Verify execution paths against an expected result path to ensure that the model arrives at the correct outcome. Prevent silent failures where an agent falsely reports success, or enters into an infinite or non-recoverable loop by asserting the results at execution steps. Use [session tracing](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5) to inspect turn-by-turn interactions, reasoning engine executions, actions, prompt and gateway inputs/outputs, error messages, and final responses.

## Resources

<table>
  <thead>
    <tr>
      <th scope="col">Agentforce</th>
      <th scope="col">Traditional Automation</th>
      <th scope="col">Integration</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5">Agentforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html">Agent Script</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5">Agentforce Grid</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5">Agentforce Operations</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5">Agentforce Service Agent and Employee Agent</a></li>
          <li><a href="https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining">Agent Script with Actions</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5">Salesforce Flow</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5">Flow Scheduled Paths</a></li>
          <li><a href="https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api">Prompt Templates</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="/docs/architect/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html">MuleSoft</a></li>
          <li><a href="https://www.mulesoft.com/ai/agent-broker">Agent Broker</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

**About the Author**

Arvind Palaniswamy is a Software Engineering Architect at the Office of the Chief Architect, Well-Architected Team. He likes to frame complex systems in their simplest forms using first principles. He understands engineering, operations, and business through decades of experience and MS/MBA(Kellogg) education.

<!-- document id=c982eadd1af8bcea9c0cffd51b64c355dd29c9b309d8083933b7e01c1b8f5452 url=/architect/next/en-us/decision-guides/guides/event-driven.md -->

# Using the Right Tools and Patterns for Event-Driven Architectures

Event-driven architectures support the efficient production and consumption of events, which communicate system or application state changes. These architectures enable flexible connections between systems, and support processes and near real-time updates that work across systems. While the advantages of event-driven architectures are easy to see, implementation details are not always as clear. What capabilities do you need to consider in event-driven architectural patterns? What specific problems do these patterns solve? What special considerations apply to your solutions, and what are the optimal patterns for addressing them?

## Guide Overview

This guide presents patterns used to build optimal event-driven architectures when working with Salesforce technologies. It also discusses eventing tools available from Salesforce, and provides tool recommendations for a selection of use cases. For information about data-level integrations involving Salesforce, see our [Data Integration Decision Guide](/docs/architect/decision-guides/guide/data-integration).

## Takeaways

- **Use event-driven architectures for processes that do not require synchronous responses to requests.** The patterns outlined in this guide are designed for data consistency, scalability, and reuse, which help to keep technical debt to a minimum as your organization's application landscape evolves. (See [Well-Architected - Reliability](/docs/architect/well-architected/guide/reliability.html) for more information.)

- **If MuleSoft or another Enterprise Service Bus (ESB) solution is part of your existing landscape, use it where possible.** These solutions are purpose-built to support event-driven architecture patterns and have powerful capabilities that enable you to reuse integrations across your enterprise.

- **Use the Pub/Sub API for any future publish/subscribe patterns instead of building your own event handlers using other APIs, including the Streaming API.** Now that the Pub/Sub API is generally available, use it for any new publish/subscribe patterns. Plan to migrate existing event communications using other platform APIs, such as the Streaming API or custom Apex services, to the Pub/Sub API when it's feasible to do so.

- **Platform events and Change Data Capture (CDC) are the preferred mechanisms for publishing record and field changes that need to be consumed by other systems.** We don't recommend using PushTopic and generic events for new implementations. Salesforce will continue to support PushTopic and generic events within current functional capabilities, but doesn't plan to make further investments in this technology.

## Products in Scope

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Salesforce Platform"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0">The <a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Platform</a> is a comprehensive, AI-driven platform that unifies employees, autonomous AI agents, company data, and applications into a single, trusted system to enhance productivity and customer experience. It enables the creation of an "agentic enterprise" by connecting Customer 360 apps, Data Cloud, and Slack for end-to-end automation.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://www.salesforce.com/mulesoft/">MuleSoft</a> is Salesforce's leading integration platform that enables organizations to connect applications, data, and devices across on-premises and cloud environments. MuleSoft is a platform that gives IT the platforms to unlock data across systems, develop scalable integration and automation frameworks, and create differentiated, connected experiences - fast.</td>
    </tr>
  </tbody>
</table>

## Decision Points

Event-Driven Architectures (EDAs) are recommended for scenarios requiring near real-time notifications, distributing processing load for high-volume or complex messages, and integrating systems like IoT and mobile devices that require connectivity resilience through queuing. However, EDAs should not be implemented for processes that demand immediate, synchronous human responses, as they are designed for asynchronous execution. Nor are they a good fit if source data changes so infrequently that a simpler pattern like batch processing would suffice.

### When to Use an Event-Driven Architecture

Here are several common scenarios that are often a good fit for an event-driven architecture:

<table style="width:100%">
<thead>
<tr><th scope="col">Decision Point</th><th scope="col">Guidance</th></tr>
</thead>
<tbody>
<tr><td><strong>Near real-time notifications</strong></td><td>Event-driven architecture patterns like publish/subscribe, fanout, and streaming tend to work well in scenarios where multiple applications need to be notified of status changes or record updates in near real-time.</td></tr>
<tr><td><strong>Parallel processing</strong></td><td>Patterns such as publish/subscribe tend to work well in scenarios where large volumes of data or highly complex messages necessitate distributing the processing load among multiple systems.</td></tr>
<tr><td><strong>High-volume reads</strong></td><td>The Passed Messages and Queuing patterns are commonly used in scenarios where organizations experience surges, and the volume of messages being produced can exceed subscribers' ability to immediately process them.</td></tr>
<tr><td><strong>High-volume writes</strong></td><td>The Streaming and Queuing patterns work well in many scenarios where organizations experience surges in the number of messages produced.</td></tr>
<tr><td><strong>Sending the same data to different systems</strong></td><td>While publish/subscribe tends to be a fairly common solution for organizations that need to send the same data to multiple systems, it can be addressed by most patterns covered here. Be sure to review them in detail to find the best fit.</td></tr>
<tr><td><strong>Frequent introduction of new systems or devices</strong></td><td>The publish/subscribe, Streaming, and Queuing patterns tend to work well for scenarios where the overall landscape tends to be in flux, with new systems and devices being added regularly. In this scenario, a new system or device simply needs to become a subscriber to the event bus or associated with a queue, to begin receiving messages rather than requiring a custom point-to-point integration.</td></tr>
<tr><td><strong>IoT devices</strong></td><td>Because IoT devices typically deliver frequent updates and can also generate a surge of messages in some scenarios, the Streaming and Queuing patterns tend to work well when integrating them into an IT landscape.</td></tr>
<tr><td><strong>Offline mobile devices and systems</strong></td><td>Mobile devices that need to work in areas with low quality or nonexistent internet access or systems that may be offline at the time messages are delivered will benefit from the Queuing pattern, which enables them to connect to their queues and retrieve any relevant messages once they're back online.</td></tr>
</tbody>
</table>

Most large organizations have complex IT landscapes that have a combination of systems with different capabilities. It's possible, or perhaps likely, that your organization has legacy systems that don't support event-driven integrations. You might also have use cases where event-driven integrations don't make sense, even if the systems will support them (for example, SFTP file transfers from third-parties). If you take a step back and look at your organization's IT landscape as a whole, chances are — just as with other architectural solutions — you'll employ a mixture of patterns to support different scenarios. When you decide to make event-driven your preferred approach to integrations, think of it as another tool in your toolbox. It can and should be used in the right scenarios, but it isn’t an approach to be imposed on every system. Developing a comprehensive integration strategy will help you determine when the patterns described in this guide may or may not be appropriate.

### When Not to Use an Event-Driven Architecture

Many scenarios call for event-driven architectures, and in some scenarios, event-driven architectures will work even if they aren't the best fit. But in some scenarios, event-driven architectures simply shouldn't be used. Here are some decision-point questions to help you identify these scenarios:

<table style="width:100%">
<thead>
<tr><th scope="col">Decision Point</th><th scope="col">Guidance/Questions to Ask</th></tr>
</thead>
<tbody>
<tr><td><strong>Business requirements</strong></td><td>Is there a genuine business need for any of the functionality described in the [When to Use an Event-Driven Architecture](#when-to-use-an-event-driven-architecture) section?</td></tr>
<tr><td><strong>Technical requirements</strong></td><td>Is the integration you're designing an obvious fit for a different pattern, such as data virtualization, batch or request/reply? In other words, are you trying to fit a square peg into a round hole?</td></tr>
<tr><td><strong>Processes requiring humans to wait for responses</strong></td><td>Any integration that involves a human waiting for a response from the target system is not a good fit for event-driven architectures, as they are designed for asynchronous execution and can't guarantee a response time. Consider whether processes like this are optimal for your organization prior to implementing technical solutions. See [Well-Architected - Operational Excellence](/docs/architect/well-architected/guide/operational-excellence.html) for more information.</td></tr>
<tr><td><strong>Infrequently changing source data</strong></td><td>If the data in your source system changes so infrequently that periodic updates are sufficient, you can likely simplify your architecture by using [batch patterns](https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) instead of event-driven patterns.</td></tr>
<tr><td><strong>Implementation requirements</strong></td><td>Do the majority of systems involved in your solution support event-driven architectures? What would be required to use event-driven architectures with the systems that don't support them (for example, upgrades, customizations, or middleware)? What level of effort would be needed to meet these requirements?</td></tr>
<tr><td><strong>Message structure stability</strong></td><td>How often will your message structures need to change? Which systems will be affected by such a change and what will the remediation process be?</td></tr>
<tr><td><strong>Organizational Governance</strong></td><td>Do you have a governance structure in place to ensure that all stakeholders are informed of and able to weigh in on changes to message structures, triggers, and other architecture- and process-related decisions?</td></tr>
<tr><td><strong>Required skill sets</strong></td><td>Does your staff have experience with event-driven architectures and will they know how to support them?</td></tr>
</tbody>
</table>

## Use Cases

There are a variety of event-driven architecture patterns. Some are general purpose patterns that can be applied in use cases that don't have any special requirements outside of being event-driven; for example, see [Well-Architected - Reliability](/docs/architect/well-architected/guide/reliability.html). Other patterns are applicable to the specific use cases discussed here, such as integrations involving large data volumes, or scenarios that call for longer message retention.

### Patterns at a Glance

The table below compares attributes of the patterns outlined in this document. Use it as a quick reference when you need to identify potential patterns for a given use case.

<table style="width:100%">
<thead>
<tr><th scope="col">Pattern</th><th scope="col">Near Real-Time</th><th scope="col">Unique Message Copy</th><th scope="col">Guarantee Delivery</th><th scope="col">Reduce Message Size</th><th scope="col">Transform Data</th></tr>
</thead>
<tbody>
<tr><td>Publish / Subscribe</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Passed Messages</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>Streaming</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Queueing</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

### Tools for Event-Driven Architecture

Salesforce offers multiple tools to help you address your event-driven use cases. This table contains a high-level overview of available tools.

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">Tool</th><th scope="col">Description</th><th scope="col">Required Skills</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Platform that enables data integration using layers of APIs.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub Connector</a></td><td>Connector for Pub/Sub API, which provides a single interface for publishing and subscribing to platform events, real-time event monitoring events, and change data capture events.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Connector that enables sending and receiving messages to queues and topics for any message service that implements the Java Message Service (JMS) specification.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Connector to move data between Apache Kafka and enterprise applications and services.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace Connector</a></td><td>A connector for Solace PubSub+ event brokers with native API integration using the JCSMP Java SDK</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>A multi-tenant, cloud messaging service that enables customers to perform advanced asynchronous messaging among their applications.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>An MQTT (Message Queuing Telemetry Transport) v3.x protocol-compliant MuleSoft extension.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP Connector</a></td><td>A connector that enables your application to publish and consume messages using an AMQP 0.9.1-compliant broker.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint Event-Driven (ASync) API</a></td><td>Industry-agnostic language that supports the publication of event-driven APIs by separating them into event, channel, and transport layers.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Multitenant cloud messaging service that enables customers to perform advanced asynchronous messaging between their applications.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint Data Streams</a></td><td>Framework available within MuleSoft Anypoint for publishing and subscribing to streaming data.</td><td>Pro-code</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Heroku add-on that provides Apache Kafka as a service with full platform integration into the Heroku platform.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Change Data Capture</a></td><td>Change events log, which publishes changes to Salesforce records. Changes include creation of a new record, updates to an existing record, deletion of a record, and undeletion of a record.</td><td>Low-code to Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Outbound Messages</a></td><td>Actions that send XML messages to external endpoints when field values are updated within Salesforce.</td><td>Low-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Platform Events</a></td><td>Secure and scalable messages that contain custom event data.</td><td>Low-code to Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>API that enables subscriptions to platform events, Change Data Capture events, and/or Real-Time Event Monitoring events.</td><td>Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Event Relays</a></td><td>Enables platform events and change data capture events to be sent from Salesforce to Amazon EventBridge. Note that Event Relays only connect to AWS Eventbridge.</td><td>Low-code</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### Publish/Subscribe

When a critical record changes state within a core application—for instance, an order's status moves from "Processing" to "Shipped"—multiple other systems likely require a near real-time notification to perform their respective tasks. A specific business need arises when the volume of these changes is high and the messages are complex, making traditional point-to-point integrations burdensome and difficult to maintain. Establishing fragile, custom connections for every single dependent application leads to technical debt and inhibits the organization's ability to scale quickly. A robust integration approach is needed to manage these frequent data synchronizations without coupling the source system directly to every consuming system.

#### The Publish/Subscribe Pattern

The diagram below depicts a typical publish/subscribe pattern with multiple publishers and subscribers sharing data through an event bus. This foundational pattern forms the basis for the more specific patterns that can be found throughout the rest of this guide. Some key characteristics of this pattern are:

- There is no direct connection between publishers and subscribers. Publishers simply send messages to an event bus, which broadcasts them to any other system that wants to listen for them.

- The same system can be both a publisher and a subscriber.

- Systems may publish or subscribe to multiple types of events.

- As with all of the patterns in this guide, the publish / subscribe pattern falls into a general integration pattern category known as remote procedure invocation (RPI) or simply ["fire and forget."](/docs/architect/fundamentals/guide/integration-patterns#remote-process-invocation--fire-and-forget)

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="This Level 2 diagram shows an example of the publish / subscribe pattern that includes multiple publishers, multiple subscribers, and multiple events being delivered through channels in an event bus. In this pattern, the same system can be both a publisher and a subscriber and a system can subscribe to multiple events.">

#### Tools Relevant to the Publish/Subscribe Pattern

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Event Flow and Behavior</th><th colspan="2" scope="colgroup">Payload Considerations</th></tr>
<tr><th scope="col">Available Tools</th><th scope="col"></th><th scope="col">Required Skills</th><th scope="col">Publish Via</th><th scope="col">Subscribe Via</th><th scope="col">Replay Period</th><th scope="col">Payload Structure</th><th scope="col">Payload Limits</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">MuleSoft Anypoint Event-Driven (ASync) API</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Pro-code</td><td>APIs, record changes in Heroku Postgres</td><td>N/A</td><td>1-6 weeks</td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Change Data Capture</a></td><td>Low-code to Pro-code</td><td>Record Changes</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Outbound Messages*</a></td><td>Low-code</td><td>Flow and Workflow Rules</td><td>N/A</td><td>24 hours</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">User Defined</a></td><td>100 notifications per message</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Platform Events</a></td><td>Low-code to Pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>Pub/Sub API or APIs, Apex, Flow</td><td>Pub/Sub API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Event Relays**</a></td><td>Low-code</td><td>Platform Events, Change Data Capture</td><td>API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Salesforce will continue to support outbound messages within current functional capabilities, but does not plan to make further investments in this technology. **Event Relays only connect to AWS Eventbridge</td></tr>
</tbody>
</table>

### Fanout

When an organization needs to send instantaneous updates to a large number of client applications, such as push notifications or SMS messages to mobile devices, the traditional process of creating unique transmissions for every single recipient quickly becomes a scalability bottleneck. The core business need, in this case, is the rapid, high-performance distribution of a single piece of information—like an account alert or a critical service change notice—to numerous endpoint applications simultaneously. A streamlined approach to meet this requirement involves routing all messages through a single queue, which acts as the central point of event information for all consuming systems. This approach improves performance by eliminating the need to manage many separate message copies.

#### The Fanout Pattern

With the fanout pattern, messages are delivered to one or multiple destinations (that is, listening clients or subscribers) through a single message queue. Subscribers retrieve the same message from the queue, rather than their own unique copy. (Note that while this improves performance, it can also make it more difficult to verify whether or not a particular subscriber received the message.)

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="This Level 3 documentation and implementation diagram shows an example of the fanout pattern. It depicts an event being published and written to a single queue when a record is modified via a user interaction, flow, or batch job. The subscriber system has multiple services that receive the same event from the message queue.">

#### Tools Relevant to the Fanout Pattern

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Event Flow and Behavior</th><th colspan="2" scope="colgroup">Payload Considerations</th></tr>
<tr><th scope="col">Available Tools</th><th scope="col"></th><th scope="col">Required Skills</th><th scope="col">Publish Via</th><th scope="col">Subscribe Via</th><th scope="col">Replay Period</th><th scope="col">Payload Structure</th><th scope="col">Payload Limits</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">MuleSoft Anypoint Solace Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Pro-code</td><td>APIs, record changes in Heroku Postgres</td><td>N/A</td><td>1-6 weeks</td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Change Data Capture</a></td><td>Low-code to Pro-code</td><td>Record Changes</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Platform Events</a></td><td>Low-code to Pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>Pub/Sub API or Apex, APIs, Flow</td><td>Pub/Sub API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Event Relays*</a></td><td>Low-code</td><td>Platform Events, Change Data Capture</td><td>API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Event Relays only send data to AWS Eventbridge</td></tr>
</tbody>
</table>

### Passed Messages

Some event scenarios are characterized by a significant influx of message volume that threatens to overwhelm the capacity of synchronization and transformation processes, or by complex, multi-step logic required to process and transform event data.

Some examples include:

- **Seasonal volume spikes:** There can be spikes in volume that online retailers experience when a selection of their products are "in season.” When large numbers of customers are making purchases at the same time, the number of events generated can temporarily exceed the capacity of synchronization and transformation processes. See [Well-Architected - Reliability](/docs/architect/well-architected/guide/reliability.html#scalability-and-capacity-planning) for more information.

- **Case or claims management:** Service-based companies can experience surges in the number of cases or claims during outages.

- **Complex data transformations:** Organizations that require complex logic to transform messages are often concerned about events being generated faster than they can be transformed.

#### The Passed Messages Pattern

This pattern addresses the challenge of messages being generated faster than they can be transformed. It ensures that large volumes of messages and required data manipulations can be handled reliably, incorporating a streaming message platform and segmenting message handling logic into dedicated components.

The Passed Messages pattern works by segmenting message handling logic into multiple components:

- One component handles message routing, determining required transformations and the final destination.

- A separate set of components handle different layers of message transformation (for example, field mappings, object relationships, and so on).

- The last component writes out the final, modified message.

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="This Level 3 documentation and implementation diagram shows an example of a process flow for the passed messages pattern that includes a publisher, a subscriber, and a message. The message is split into multiple parts, which are transformed individually and then reassembled prior to being sent to the subscriber.">

#### Tools Relevant to the Passed Messages Pattern

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Event Flow and Behavior</th><th colspan="2" scope="colgroup">Payload Considerations</th></tr>
<tr><th scope="col">Available Tools</th><th scope="col"></th><th scope="col">Required Skills</th><th scope="col">Publish Via</th><th scope="col">Subscribe Via</th><th scope="col">Replay Period</th><th scope="col">Payload Structure</th><th scope="col">Payload Limits</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Pro-code</td><td>APIs, record changes in Heroku Postgres</td><td>N/A</td><td>1-6 weeks</td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Change Data Capture</a></td><td>Low-code to Pro-code</td><td>Record Changes</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Platform Events</a></td><td>Low-code to Pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>Pub/Sub API or APIs, Apex Flow</td><td>Pub/Sub API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Event Relays*</a></td><td>Low-code</td><td>Platform Events, Change Data Capture</td><td>API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Event Relays only send data to AWS Eventbridge</td></tr>
</tbody>
</table>

### Streaming

Some producers generate a continuous stream of events. A common example is media streaming, which involves user interactions that naturally occur as discrete events. Multiple systems must react to the same user behavior simultaneously without blocking the core streaming experience.

Consider the events for a music streaming platform. These might include:

- Track started/paused/skipped events

- Listening session events with timestamps

- Playlist creation/modification events

- Social sharing events

- Download for offline listening

#### The Streaming Pattern

In the Streaming pattern, subscribers access each event stream, and process the events in the exact order in which they are received. Unique copies of each message stream are sent to each subscriber, making it possible to deliver subscriber-specific content, and to identify which subscribers receive which streams.

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="This Level 3 documentation and implementation diagram shows an example of the streaming pattern that depicts a stream of events being published. Subscribers that are listening for the streams receive them and process them accordingly.">

#### Tools Relevant to the Streaming Pattern

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Event Flow and Behavior</th><th colspan="2" scope="colgroup">Payload Considerations</th></tr>
<tr><th scope="col">Available Tools</th><th scope="col"></th><th scope="col">Required Skills</th><th scope="col">Publish Via</th><th scope="col">Subscribe Via</th><th scope="col">Replay Period</th><th scope="col">Payload Structure</th><th scope="col">Payload Limits</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint Data Streams</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Pro-code</td><td>APIs, record changes in Heroku Postgres</td><td>N/A</td><td>1-6 weeks</td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>Pub/Sub API or APIs, Apex Flow</td><td>Pub/Sub API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">User Defined</a></td><td>1 MB</td></tr>
</tbody>
</table>

#### Streamed Event Order Management

For a stream to make sense, all of its events and their associated messages need to be in the correct order. If you source the data in a stream from different systems, you'll need to incorporate additional ordering logic as part of the design process.

### Queuing

Queuing use cases are ubiquitous. Examples include:

- **Low quality internet connections:** Field service organizations or other organizations where teams with mobile devices need to work in areas with low quality or intermittent internet access benefit from queuing because the applications on these devices can connect to their queues and retrieve any relevant messages when connectivity is restored.

- **Message buffering:** When message volume occasionally exceeds a subscriber's processing capacity and increased latency will not create additional issues, queues can be a buffer to store excess messages and prevent data loss.

- **Transportation management:** Logistics organizations that need to monitor their fleets can use this pattern to view the routes that each vehicle is taking in near real-time and ensure that drivers are being as efficient as possible.

- **IoT devices:** Manufacturers often use systems that generate rapid streams of data, and these streams can have downstream effects on additional systems. This pattern can be used to identify sequences of events that require human intervention before catastrophic failures spanning multiple systems occur.

#### The Queuing Pattern

In the Queuing pattern, producers send messages to queues, which hold the messages until subscribers retrieve them. Most message queues follow first-in, first-out (FIFO) ordering and delete every message after it is retrieved. Each subscriber has a unique queue, which requires additional set up steps but makes it possible to guarantee delivery and identify which subscribers received which messages.

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="This Level 3 documentation and implementation diagram shows an example of the queuing pattern that depicts an event being published and written to a queue when a record is modified. Subscribers receive copies of the event from their associated queues and make the appropriate updates to their own records.">

#### Tools Relevant to the Queuing Pattern

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Event Flow and Behavior</th><th colspan="2" scope="colgroup">Payload Considerations</th></tr>
<tr><th scope="col">Available Tools</th><th scope="col"></th><th scope="col">Required Skills</th><th scope="col">Publish Via</th><th scope="col">Subscribe Via</th><th scope="col">Replay Period</th><th scope="col">Payload Structure</th><th scope="col">Payload Limits</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Salesforce Pub/Sub Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">MuleSoft Anypoint MQTT Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">MuleSoft Anypoint AMQP Connector</a></td><td>Pro-code</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">As Configured</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">User Defined</a></td><td>None</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Pro-code</td><td>APIs, record changes in Heroku Postgres</td><td>N/A</td><td>1-6 weeks</td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">User Defined</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Change Data Capture</a></td><td>Low-code to Pro-code</td><td>Record Changes</td><td>Apex, APIs, Lightning Web Components (LWC)</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Platform Events</a></td><td>Low-code to Pro-code</td><td>APIs, Apex, Flow</td><td>Apex, APIs, Flow, LWC</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Pro-code</td><td>Pub/Sub API or APIs, Apex, Flow</td><td>Pub/Sub API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">User Defined</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Event Relays*</a></td><td>Low-code</td><td>Platform Events, Change Data Capture</td><td>API</td><td>3 days</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">User Defined</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Event Relays only send data to AWS Eventbridge</td></tr>
</tbody>
</table>

#### Memory and Storage Management

Because of the asynchronous nature of the Queuing pattern, there can be a lengthy delay between a message being added to a queue and that message being retrieved. Queues require memory or storage space to hold their messages, so they can't grow indefinitely, which means that a subscriber that is offline indefinitely can cause a failure if enough messages build up in the queue. Message buffering can have the same effect if subscriber processing times become too long, causing high volumes of messages to build up in their queues. To mitigate these risks, perform a thorough analysis of storage requirements for all message queues and, if necessary, design processes that will purge and disable queues if messages aren't retrieved within a set amount of time or when they reach a predetermined volume.

## Non-Functional Considerations

In addition to the functional considerations listed in the previous sections, there are also non-functional considerations to factor into your decision.

### Migration from Point-to-Point Integrations

Even if you're fully convinced that an event-driven architecture is right for your organization, you may be starting with a landscape that already has a large number of point-to-point integrations. Getting funding for a project to replace all your integrations at once can be difficult, and it might not even be possible to use an event-driven architecture directly with some legacy systems. In these scenarios, you can take an incremental approach to migrating to a more loosely coupled architecture by converting the most business-critical applications first, then converting other systems as they get updated or replaced in future projects. This approach makes it easy to add new applications to the event bus, and enables your overall IT landscape to stay scalable and resilient as systems continue to get added over time.

### Tradeoffs within Loosely Coupled Systems

As architects, we know that every architecture comes with tradeoffs. An event-driven architecture is no exception. While a landscape full of loosely coupled systems is highly scalable and resilient, there are some tradeoffs to consider as well:

- **Overall integration strategy:** Regardless of the tools and patterns you decide to use, it's important to start by creating a strategy for how data will be shared across the various systems in your organization's landscape. This strategy should include your organization's goals for its data, how data can be shared and patterns used, as well as data sources, targets, structures, and ownership and access requirements.

- **Support for legacy systems:** Your organization may have legacy systems that simply don't support event-driven architecture patterns. While it may be possible to build workarounds (for example, with a process that acts as a pass-through by subscribing to events and then sending the output to the target system via a different means of data transfer), you may want to consider other integration methods in this case.

- **Structural changes to messages:** Once the initial message structure is defined and agreed to between publishers and subscribers, it can be difficult to change, particularly if the subscribers are external. There are several ways to address this issue. You can use versioned endpoints, but make sure to define and communicate a clear lifecycle for each version so that your developers won't have to maintain too many versions simultaneously. If Apache Kafka on Heroku is part of your landscape, you can also consider a schema registry or similar tool, but make sure the other systems in your landscape support it (and use it) as well.

- **Lack of visibility between publishers and subscribers:** In most event-driven architecture patterns, the publishers aren't aware of the status of their subscribers. So, if a publisher sends a critical message while all subscribers are offline, the message may never get delivered. You can address this issue by making use of replay functionality or adding redundant subscribers that run on separate servers for all critical messages.

- **Performance bottlenecks:** As an event-driven architecture scales, the event bus can become a bottleneck for message delivery if it gets overwhelmed with too many publishers trying to message too many subscribers simultaneously. You can address this by increasing the memory and processing resources allocated to the event bus or by using multiple event buses to process different types of messages in parallel.

## Related Best Practices

In addition to the guidance already provided, also consider the following best practices.

### Implementing Event-Driven Architectures

Before implementing an event-driven architecture, consider if you truly need to be using one in the first place. The previous section describes common business scenarios that are good fits for each event-driven architecture pattern. You can also read more in [Well-Architected - Reliability](/docs/architect/well-architected/guide/reliability.html). Review Challenges to Consider when Implementing Event Driven Architectures to determine if the patterns you have in mind are the best fit for your specific use cases.

Note that while the majority of the scenarios covered in this guide involve integrations, event-driven architectures can also be used to send messages within a single Salesforce org through the use of platform events, for example. Make sure to keep any applicable [event allocation limits](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) in mind when designing processes that use platform events as an internal messaging system.

### Avoiding Anti-Patterns

Frequently, anti-patterns around event-driven architectures come from using events as a workaround for internal communications within a Salesforce org. Common anti-patterns include:

- **Publishing events from Apex triggers associated with the same event object:** This will result in an infinite trigger loop.

- **Publishing events from Apex before a DML transaction completes:** If a transaction fails and rolls back, any published events that have the Publish Immediately publish behavior won't be included in the rollback behavior.

- **Publishing events in Flow to orchestrate subsequent automation:** The best way to coordinate logic across multiple automations is to use [subflows](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) or [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm).

- **Creating runtime dependencies:** Don't publish events to facilitate communication between packages without taking the proper [steps](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) to eliminate runtime dependencies.

- **Unnecessarily large payloads:** When making requests, it's best to send and receive the smallest amount of data possible in the payload. Every action by a user could potentially spawn multiple requests, and it is important that these are processed efficiently. Sending more data than necessary can contribute to slow transport and increased processing time.

- **Unselective handling of application events:** When there are multiple components listening for an application event, developers should ensure the event handler will only execute when it is actually desired and useful. For example, in the Lightning Console, components contained in tabs that are not focused can still be listening even though they are not visible. A developer can use various techniques such as using a background utility item as the only listener, or calling getEnclosingTabId() to determine whether this instance of the component is enclosed within the focused tab to ensure each event is handled only when it is intended.

- **Using Platform Events publish behavior incorrectly:** Platform Events have two publishing behaviors — Publish Immediately and Publish After Commit. It can be useful to use real-time platform events for use cases such as Logging, where you want to publish the logging event regardless of whether the transaction succeeds and commits. However, use Publish Immediately very carefully with real-time platform events. Events can be consumed by subscribers within the same transaction and cause row locks or other race conditions.

### Designing Effective Events

When implementing an event-driven architecture, one of the keys to success is to set standards for how the events themselves are designed. Specifics will vary depending on your organization's use cases, but here are some general guidelines:

- **Determine the optimal structure for your event payloads.** While smaller message sizes reduce processing times, bombarding subscribers with massive volumes of messages can cause performance bottlenecks. You may need to iterate on your payload sizes and structures to find the right balance. MuleSoft and similar ESB tools provide the ability to design custom payloads in the messages associated with your events, which can help you visualize data structures to improve performance on the subscriber side. (See [Well-Architected - Reliability](/docs/architect/well-architected/guide/reliability.html) for more information.)

- **Think about your processes end-to-end.** Make sure you're not creating any "endless loop" scenarios, which can be difficult to track down once the integrations have been rolled out. An example of this would be two systems that publish events when records are updated, while also listening for each other's events, which trigger additional published events when they're processed.

  You can fix this type of anti-pattern by adding logic to both systems that ensures that changes made as the result of an event being consumed do not result in publishing a new event. You should also make sure to document all of your events, their associated triggers, and the downstream systems that may be affected. Use this documentation as a reference during design sessions to help catch endless loops and similar scenarios as early as possible. (See [Well-Architected - Operational Excellence](/docs/architect/well-architected/guide/operational-excellence.html) for more information.)

- **Use common naming conventions across systems.** Consistent naming conventions are a best practice for all software development, including event-driven architectures. Take time to document a set of standards for event names, structures, associated objects, and error handling processes to ensure consistency across systems. (See [Well-Architected - Operational Excellence](/docs/architect/well-architected/guide/operational-excellence.html) for more information.)

## Resources

<table style="width:100%">
<thead>
<tr><th scope="col">Pattern</th><th scope="col">Resources</th></tr>
</thead>
<tbody>
<tr><td>Publish/ Subscribe</td><td><a href="/docs/architect/well-architected/guide/reliability.html">Salesforce Well-Architected - Reliability</a><br><a href="/docs/architect/well-architected/guide/operational-excellence.html">Salesforce Well-Architected - Operational Excellence</a><br><a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">Blog Post: Achieve Architectural Efficiency with Event Relays</a><br><a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">Blog Post: Announcing Pub/Sub API Generally Available</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">Blog Post: Moving from RESTful to EVENTful</a><br><a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">Blog Post: Event-Driven Architectures and the AsyncAPI Specification</a><br><a href="https://youtu.be/0WJjmmw1ryM">Video: Publish / Subscribe Pattern Walkthrough</a></td></tr>
<tr><td>Fanout</td><td><a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">Blog Post: How to Work Within Platform Events Delivery Limits</a><br><a href="https://youtu.be/zSncRUcucEU">Video: Fanout Pattern Walkthrough</a></td></tr>
<tr><td>Passed Messages</td><td><a href="https://youtu.be/U87nErhMuqw">Video: Passed Messages Pattern Walkthrough</a></td></tr>
<tr><td>Streaming</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Blog Post: Designing for High-Volume Writes in Salesforce</a><br><a href="https://youtu.be/-_1CDUI40fY">Video: Streaming Pattern Walkthrough</a><br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">Documentation: Streaming in Mule Apps</a></td></tr>
<tr><td>Queuing</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Blog Post: Designing for High-Volume Writes in Salesforce</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">Blog Post: How to Design Payment Architectures with Evented APIs</a><br><a href="https://youtu.be/jQvSKbMRbh0">Video: Queueing Pattern Walkthrough</a></td></tr>
</tbody>
</table>

<!-- document id=b0f655eb1dc2817e25045b3301531691a4738a2aa3b81ef687dd02665dc0c03b url=/architect/next/en-us/decision-guides/guides/get-started-data-360-decision-guides.md -->

# Get Started with Data 360 Decision Guides

This section provides practical guidance for making critical architectural decisions about Salesforce Data 360, including provisioning strategies, multi-org connectivity, and integration patterns. Use these guides to design and implement effective data architectures that unify customer data and enable AI-powered features.

---

## Data 360 Provisioning

[Data 360 Provisioning](/docs/architect/decision-guides/guide/data-360-provisioning) covers foundational decisions when provisioning Salesforce Data 360:

- **Home Org Selection**: Decide whether to provision Data 360 in an existing production org or create a dedicated org, considering governance, compliance, and time-to-value.
- **Multi-Org Strategy**: Choose between multiple independent Data 360 instances or using Data Cloud One to unify multiple Salesforce orgs, balancing autonomy, compliance, and cost.
- **Data Cloud One Architecture**: Enable multiple Companion Orgs to share a single Data 360 instance with centralized governance, metadata sharing, and feature parity across orgs.
- **Data Sharing Between Data 360 Orgs**: Use zero-copy data sharing between independent instances for regional compliance, business unit collaboration, or federated executive dashboards.
- **Provisioning Considerations**: Factor in data residency, governance models, latency, integration complexity, cost, and AI readiness for enterprise-wide deployments.

Helps architects design provisioning strategies that ensure simplicity, enterprise consistency, compliance, and scalability for Customer 360, AI, and cross-platform innovation.

---

## Data 360 Interoperability

[Data 360 Interoperability](/docs/architect/decision-guides/guide/data-360-interoperability) provides a framework for integrating Data 360 with external platforms and data lakes:

- **Data Ingestion Patterns**: Real-time, streaming, and batch ingestion for creating governed canonical datasets ideal for Customer 360, compliance, and centralized governance.
- **Zero-Copy Data Federation**: Live query, accelerated query (caching), and file federation methods to access external systems in real time without duplication, enabling personalization, dashboards, and AI/ML workloads.
- **Hybrid Approach**: Combine governed ingestion for core datasets with zero-copy federation for freshness and scalability, supporting omni-channel engagement, Agentforce-driven actions, and enterprise analytics.
- **Decision Framework**: Evaluate trade-offs in latency, cost, scalability, governance, and complexity to select the right integration pattern per data source.
- **Architect Playbooks**: Industry-specific guidance, design practices, and cost considerations for finance, healthcare, retail, and telecom scenarios.

Guides architects in balancing data freshness, governance, and pipeline efficiency to build scalable, interoperable, AI-ready data architectures that support both operational and analytical workloads.

<!-- document id=58ce3c44c6fc9a910da793835050543815a39ac22b984bd413a51e4a3f337c76 url=/architect/next/en-us/decision-guides/guides/get-started-integration-decision-guides.md -->

# Get Started with Integration Decision Guides

This section provides practical guidance for choosing the right data integration tools and approaches for Salesforce. It covers outbound integrations, inbound integrations, and cross-org scenarios, helping architects design and implement data-layer integrations that balance performance, maintainability, and cost.

---

## Data Integration with Salesforce

[Data Integration with Salesforce](/docs/architect/decision-guides/guide/data-integration) provides a comprehensive overview of Salesforce data integration tools and best practices:

- **Integration Tool Landscape**: Overview of Salesforce data integration tools, including low-code, hybrid, and pro-code options, with guidance on selecting the right tool for specific use cases.
- **Outbound Integrations**: Methods for sending data from Salesforce to external systems, including Change Data Capture, External Services, Heroku Connect, OmniStudio Integration Procedures, Salesforce Connect, MuleSoft Anypoint, and custom Apex solutions.
- **Inbound Integrations**: Approaches for bringing external data into Salesforce, with guidance on data replication versus virtualization and when to use each tool.
- **Cross-Org Integrations**: Recommended methods for sharing data between Salesforce orgs, including MuleSoft Anypoint, Heroku Connect, Native Salesforce APIs, Change Data Capture, and Salesforce Connect with Cross-Org Adapter, including guidance for replacing legacy Salesforce-to-Salesforce implementations.
- **Decision Framework**: Key considerations for selecting integration tools, such as existing tools and landscape, data flow requirements (timing, directionality, expected user experience), implementation complexity, maintainability, data volume, and platform limits.

Enables architects to choose the right integration tools and patterns for each scenario, minimizing unnecessary data replication, leveraging existing ESB/ETL solutions, and ensuring scalable, maintainable integrations that align with enterprise architecture principles.

<!-- document id=b7a96374510efabdaf2f05ed10074975762ea812d78b78f5c3535168bd4537a3 url=/architect/next/en-us/decision-guides/guides/get-started-platform-decision-guides.md -->

# Get Started with Platform Decision Guides

This section provides practical guidance for making critical architectural decisions about Salesforce Platform capabilities. It covers asynchronous processing, record-triggered events, form building, agentic and traditional workflow automation, event-driven architecture, and step-based async frameworks to help architects design scalable, maintainable, and high-performance platform solutions.

---

## Asynchronous Processing

[Asynchronous Processing](/docs/architect/decision-guides/guide/async-processing) provides guidance on tools and approaches for asynchronous operations in Salesforce:

- **Asynchronous Processing Tools**: Comparison of Queueable Apex, Scheduled Apex, Platform Event Triggers, Change Data Capture, Scheduled Path (After Commit Flows), and Asynchronous Path (Record-Triggered Flows), with guidance on appropriate use cases.
- **Server-Side Asynchronous Processing**: Patterns for long-running database operations, external callouts, and large-volume record processing.
- **Client-Side Asynchronous Processing**: Techniques like Apex Continuation Callouts and client-side asynchronous processing that may execute in browsers or mobile apps.
- **Decision Framework**: Consider use case validation, scalability, understanding when transactions are truly asynchronous, monitoring, and handling extreme load events.
- **Best Practices and Anti-Patterns**: Guidance for proper use, including outbound integrations, monitoring, and avoiding common pitfalls.

Enables architects to implement scalable, reliable, and maintainable asynchronous patterns, avoiding pitfalls that compromise performance.

---

## Building Forms

[Building Forms](/docs/architect/decision-guides/guide/build-forms) guides architects on Salesforce form-building options:

- **Form-Building Tools**: Comparison of Dynamic Forms, Screen Flow, OmniStudio, Screen Flow with Lightning Web Components (LWC), and LWC, including skills and licensing considerations.
- **Decision Framework**: Consider object impact, form scope, navigation, location (app, mobile, web), UX, and test automation.
- **Tool Selection Guidance**: Recommendations from simple record layouts to multi-page wizards and branded customer-facing forms.
- **Combination Patterns**: Guidance for combining tools, e.g., Screen Flow navigation with LWC styling.
- **Advanced Features**: Deep dives into capabilities and limitations to inform tool choice.

Helps architects select the right form-building approach for their specific UX, functional, and integration requirements.

---

## Determining Agentic and Traditional Workflow Automation

[Determining Agentic and Traditional Workflow Automation](/docs/architect/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) provides a framework for choosing between traditional automation and Agentforce using the Orchestration Density framework:

- **Orchestration Density Framework**: Evaluates automation complexity based on execution path (fully specifiable vs. non-specifiable), goal complexity (single task vs. competing goals), and modality mix (structured vs. multi-modal inputs).
- **Product Landscape**: Comparison of Flows, Apex, Agentforce, Agent Script, Agentforce Grid, Agentforce Operations, and MuleSoft for different automation scenarios.
- **Density Selection Matrix**: Maps orchestration density levels (low, medium, high) to architectural standards, from record-triggered automation to hybrid orchestration to guided determinism with Agent Script.
- **Decision Framework**: Sequential evaluation process—inspect execution path first, then goal complexity, then modality mix—to determine the right tool.
- **Use Case Guidance**: Specific recommendations for traditional automation (rule-based, deterministic), Agentforce Grid (bulk AI tasks), hybrid orchestration (complex end-to-end processes), and Agent Script (unstructured entry points with reasoning needs).

Enables architects to make informed decisions across the automation spectrum, balancing reasoning capabilities with deterministic control for scalable, auditable, and maintainable solutions.

---

## Event-Driven Architecture

[Event-Driven Architecture](/docs/architect/decision-guides/guide/event-driven) provides a comprehensive guide to Salesforce eventing tools and patterns:

- **Eventing Tools**: Overview of Platform Events, Change Data Capture, Pub/Sub API, MuleSoft Anypoint, Streaming API, and integration considerations.
- **Event-Driven Patterns**: Includes publish/subscribe, fanout, passed messages, streaming, and queueing patterns for various event-driven use cases.
- **Integration with MuleSoft**: Using Anypoint connectors (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) for enterprise architectures.
- **Platform Events and Change Data Capture**: Guidance on preferred mechanisms for publishing record and field changes, with migration from PushTopic/Generic Events.
- **Implementation Patterns**: Best practices for scalability, consistency, error handling, and monitoring.

Enables architects to design scalable, near real-time event-driven systems that connect multiple systems efficiently.

---

## Step-Based Async Framework

[Step-Based Async Framework](/docs/architect/decision-guides/guide/step-based-async-framework) provides a framework for modular, scalable asynchronous job processing:

- **Framework Architecture**: Components include Queueable Apex, Finalizers, Scheduled Flow, Apex Cursors, Invocable Actions, and Slack integrations.
- **Step-Based Processing**: Breaks work into independent steps that can run, retry, and restart with shared governance and operational visibility.
- **Implementation Guidance**: Patterns for Step interface, Step Processor, Apex Invocable layer, delay handling, and notifications.
- **Best Practices**: Recommended when most information exists in CRM, for high-volume workloads, and hierarchical or tree-based record processing; guidance on when not to use.
- **Enterprise-Grade Features**: Governance, compliance, distributed state, progress tracking, SLA monitoring, failure diagnostics, and audit-level logging.

Provides architects a scalable alternative to monolithic batch jobs and chained async calls, supporting high-volume Salesforce workloads with full operational transparency.

---

## Record-Triggered Automation

[Record-Triggered Automation](/docs/architect/decision-guides/guide/record-triggered) provides the framework for designing record-triggered automation on the Salesforce Platform:

- **Tool Selection**: When to use Record-Triggered Flow versus Apex triggers, guided by automation density (low, medium, high) and the density selection matrix.
- **Automation Density**: How to assess automation quantity, record volume, and dependency sprawl to choose Flow, hybrid (Flow with Invocable Apex), or Apex triggers.
- **Entry Points and Governance**: One entry point per Salesforce Object; guidance on entry conditions, recursion control, and ordered execution.
- **Asynchronous Invocation**: When and how to invoke asynchronous processes from record-triggered flows or Apex, with caution around error handling and governor limits.
- **Best Practices**: Patterns for bulkification, hybrid Flow–Apex design, and avoiding common pitfalls in trigger automation.

Enables architects to design scalable, maintainable, and performant record-triggered automation aligned with platform standards.

<!-- document id=3e1eede7389a26da7e44d5f8da09d5cffdfe962d0091a8ace448b1ee049be064 url=/architect/next/en-us/decision-guides/guides/record-triggered.md -->

# Record-Triggered Automation

The Salesforce Platform has continuously advanced its automation architecture to meet the demands of complex business processes. Earlier generations — Workflow Rules and Process Builder — provided the initial steps in event-driven logic, expanding automation capabilities for event-driven logic and broadening the reach to a wider range of builders.

This evolution has culminated in a high-performance, consolidated architecture centered on two complementary pillars: Record-Triggered Flow and Apex Triggers.

## Guide Overview

This document provides the framework and guidelines to make informed decisions when designing trigger automations. It balances use case requirements against three major decision points that will guide you to choosing the right approach for automation triggered by changes to Salesforce records.

## Products in Scope

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Flow</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Salesforce Flow</a> is a powerful, point-and-click automation tool that lets users build complex business processes, screens, and logic visually using Flow Builder, without writing code. It automates tasks like data updates, sending emails, and guiding users, offering flexibility through types like Screen Flows (user interaction) and Triggered Flows (record/scheduled events).</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0"><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a> is a proprietary, object-oriented programming language for the Salesforce platform, similar to Java, used to build custom business logic, automate processes, and extend core CRM functionalities beyond declarative tools.</td>
    </tr>
  </tbody>
</table>

## Takeaways

Building scalable, maintainable, and performant record-triggered automation on the Salesforce Platform requires a disciplined, architecture-led approach. The choice between Flow and Apex, and the implementation of each, is guided by a clear set of principles. These points summarize these principles and serve as the foundational rules for modern automation design.

- **Choose the right tool for the job based on Salesforce Object automation density.**

  - Use Record-Triggered Flow for Salesforce Objects for **low density** automations.

  - Augment Record-Triggered Flow logic with Invocable Apex for **medium density** automations.

  - Use Apex triggers for Salesforce Objects for **high density** automations.

- **Exercise caution when triggering asynchronous processes.**  
  This rule applies whether you're invoking asynchronous processes in a record-triggered flow or enqueuing a queueable job from Apex. While this pattern can be tempting for offloading work, it can introduce complex error-handling scenarios and increase the risk of hitting governor limits.

- **Use one entry point per Salesforce Object.**  
  For a given Salesforce Object, use one mechanism as your entry point into automation. Try to avoid mixing Flow and Apex triggers as entry points for the same Object.

## Decision Points

There are three main decision points for consideration:

- Declarative Versus Programmatic Implementation
- Automation Density
- The Density Selection Matrix

### Declarative Versus Programmatic Implementation

Flow and Apex share a common set of fundamental capabilities. Each tool can query records, execute conditional logic, assign variables, and perform DML operations like creating, updating, and deleting records — sequenced to run in a specified order.

However, this functional overlap does not imply that the tools are interchangeable. The architectural choice is not about _if_ a task can be accomplished, but _how_ it is accomplished and what the long-term implications are for performance, scalability, and maintainability. Flow excels in declarative clarity and speed of implementation for straightforward processes, while Apex provides the granular control and raw power necessary for complex solutions.

### Automation Density

**Automation density** is the load placed on a specific Salesforce Object. It serves as a heuristic to determine the object's optimal implementation. As automation density grows, the likelihood of breaching transactional limits increases.

Calculate automation density by inspecting three specific dimensions of volume and complexity:

- **Automation quantity:** The raw number of unique automation metadata entries (flows, trigger actions, and so on) that execute during a single Data Manipulation Language (DML) event.

- **Record volume:** The records per transaction processed via API loads or heavy batch processing, where performance becomes critical.

- **Dependency sprawl:** A measure of the downstream DML operations triggered by the initial CRUD operation. It quantifies the depth of the graph where one update cascades into updates on related objects (for example, case → account → contact → custom rollup).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="Automation density dimensions">

As the scope and complexity of your Salesforce application grows, commit to a single primary entry point—either Record-Triggered Flow or Apex Triggers. Avoid partitioning automations across multiple mechanisms on a single Salesforce Object, as it leads to poor maintainability and fragmented governance.

### The Density Selection Matrix

Use this matrix to determine the required architectural standard for your Salesforce Object.

- **Record-Triggered Flow** is the preferred solution for low automation density. It offers a balance of power and accessibility that is ideal for automations that are straightforward and independent of each other.

- **The hybrid pattern (Record-Triggered Flow with Invocable Apex)** is a powerful and maintainable choice for medium-density automations with rising complexity. This pattern empowers teams to maintain ordered choreography in declarative Flow while delegating compute-heavy operations to Apex, balancing accessibility with performance.

- **Apex triggers** provide the necessary building blocks for a solid architectural foundation to support high-density automations. The performance, granular control, and object-oriented abstraction and polymorphism of Apex are better suited for managing the complexity and scale of these scenarios.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">Density Level</th>
      <th scope="col" style="width:18%">Automation Quantity</th>
      <th scope="col">Data Volume (Batch Size)</th>
      <th scope="col">Dependency Sprawl</th>
      <th scope="col">Architectural Standard</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Low</b></td>
      <td><b>&lt; 15</b><br>
        Automations</td>
      <td><b>Standard</b><br>
        User-driven UI interactions or small API loads (1–200 records)</td>
      <td><b>Discrete</b><br>
        Self-contained logic. 0–1 downstream DML operations on the same object or a related object.</td>
      <td><b>Record-Triggered Flow</b></td>
    </tr>
    <tr>
      <td><b>Medium</b></td>
      <td><b>15–30</b><br>
        Automations</td>
      <td><b>Moderate</b><br>
        Standard batch processing (with logic requiring careful bulkification)</td>
      <td><b>Coupled</b><br>
        Parent/Child updates 2–4 downstream DML operations. Risk of recursion</td>
      <td><b>Hybrid Pattern</b><br>
        Flow + invocable Apex</td>
    </tr>
    <tr>
      <td><b>High</b></td>
      <td><b>&gt; 30</b><br>
        Automations</td>
      <td><b>High</b><br>
        Large data volumes with bulk API loads (2,000 – 10,000+ records)</td>
      <td><b>Complex and Recursive</b><br>
        Deep dependency graph (5+ downstream DML operations). Risk of triangular recursion loops</td>
      <td><b>Apex Trigger Metadata Framework</b></td>
    </tr>
  </tbody>
</table>
Real-world architectural decisions require you to weigh all dimensions of automation density collectively. Consider the potential future scope when selecting an automation mechanism for a given Salesforce Object.

Also, consider the total daily number of DML operations because Salesforce enforces shared resource management in a multitenant environment and [governor limits](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) to prevent runaway automations from monopolizing shared resources. Salesforce objects with high daily DML volume require careful automation selection. For example, asynchronous limits for CPU time (60,000 ms) and heap size (12 MB) are higher than synchronous limits. Furthermore, the org-wide 24-hour limit on asynchronous executions—calculated as 250,000, or 200 times your user licenses—necessitates factoring total daily DML into your architectural design to avoid runtime exceptions.

## Product Comparison

Record-Triggered Flow is the platform's premier declarative tool for record-triggered automation. Flow's ease of use and built-in platform safeguards enable teams to easily build scalable and reliable solutions. It's the ideal choice for most teams building solutions on the Salesforce platform.

Apex is the platform's proprietary, strongly typed, object-oriented programming language. Use Apex for Salesforce objects with high automation density, and for use cases that require high performance, sophisticated logic, or granular control over transactions.

To assist in the decision-making process, this matrix provides a direct comparison of Flow and Apex across key architectural capabilities.

<table>
  <thead>
    <tr>
      <th scope="col">Capability</th>
      <th scope="col">Record-Triggered Flow</th>
      <th scope="col">Apex Trigger</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Speed of delivery and maintenance</b></td>
      <td><b>Recommended</b><br>
        The visual user interface of Flow Builder allows administrators and other declarative builders to create and modify automation faster than writing, testing, and deploying Apex code. This interface empowers a broader range of team members to deliver business value and reduces the dependency on specialized developer resources for simple tasks.</td>
      <td><b>Requires expertise</b><br>
        Apex requires properly skilled software developers to implement, test, and maintain the code.</td>
    </tr>
    <tr>
      <td><b>Modularity</b></td>
      <td><b>Available</b><br>
        Record-triggered flows are modular by default. Instead of monolithic logic, teams build discrete flows for specific requirements and choreograph them together using Flow Trigger Explorer. This modularity enables isolated modification and simple extension, vastly reducing the long-term cost of ownership.</td>
      <td><b>Available</b><br>
        Apex is divided into functional modules by design. Each Apex class is intended to implement a single module of functionality.</td>
    </tr>
    <tr>
      <td><b>Visibility and governance</b></td>
      <td><b>Recommended</b><br>
        The visual nature of Flow provides an intuitive representation of business logic. Flow Trigger Explorer provides a consolidated view of all flows on an object, making it easier for architects and administrators to understand, govern, and troubleshoot without reading code.</td>
      <td><b>Requires expertise</b><br>
        Using a metadata framework to organize triggers is advantageous, but Apex requires a disciplined development team to keep the code organized and maintainable.</td>
    </tr>
    <tr>
      <td><b>High-performance bulk data processing</b></td>
      <td><b>Not recommended</b><br>
        There is an elevated risk of hitting governor limits when dealing with complex logic or large data volumes.</td>
      <td><b>Recommended</b><br>
        Apex code executes closer to the platform's core services and offers developers enhanced control over query optimization, data handling, and algorithmic efficiency. This results in better performance and scale, especially in complex scenarios involving large data volumes.</td>
    </tr>
    <tr>
      <td><b>Robust logic and data structures</b></td>
      <td><b>Available</b><br>
        The <a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Flow Transform Element</a> can help with some complex processing tasks. However, Flow lacks native Map and Set data structures, making complex data processing cumbersome and computationally inefficient.</td>
      <td><b>Recommended</b><br>
        Apex provides full access to Map, Set, and programmatic loops for highly efficient, bulk-safe data manipulation. As a full-featured programming language, Apex also provides access to complex logical constructs, data structures, and design patterns that can help solve complex business problems in a maintainable and efficient manner. Apex includes a rich standard library of advanced functions (for example, BusinessHours, Crypto) not currently available in declarative tools.</td>
    </tr>
    <tr>
      <td><b>Transaction control</b></td>
      <td><b>Not Available</b><br>
        Flow provides no access to `Database.savepoint`, `Database.rollback`, or partially successful DML operations for partial transaction commits or rollbacks.</td>
      <td><b>Available</b><br>
        Apex provides full, granular control over transaction integrity and complex error recovery scenarios.</td>
    </tr>
    <tr>
      <td><b>Email distribution</b></td>
      <td><b>Recommended</b><br>
        Sending preconfigured email alerts from a record-triggered flow is easy and scalable. Custom email alerts can be crafted and distributed at runtime. Custom emails are subject to <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">daily email send limits</a>.</td>
      <td><b>Available</b><br>
        Apex can generate and send custom email messages. All emails sent from Apex are subject to the <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">daily email send limits</a>.</td>
    </tr>
    <tr>
      <td><b>Applying platform safeguards</b></td>
      <td><b>Recommended</b><br>
        Flow includes built-in protections, such as auto-bulkification and automatic retries. These safeguards increase the speed to value and prevent performance pitfalls that otherwise require complex, manual coding.</td>
      <td><b>Manual implementation required</b><br>
        Safeguards like bulkification must be explicitly coded (for example, managing collections and avoiding SOQL inside loops). Automatic retries are not native to triggers and require complex custom logic to implement.</td>
    </tr>
    <tr>
      <td><b>Asynchronous processing</b></td>
      <td><b>Available</b><br>
        Flow offers easy mechanisms for automations which require a separate transaction in an asynchronous path. These automations are subject to daily limits.</td>
      <td><b>Available</b><br>
        Apex enables full control via Change Data Capture and queueable events that are handled by a decoupled trigger subscriber.</td>
    </tr>
    <tr>
      <td><b>Scheduled processing</b></td>
      <td><b>Recommended</b><br>
        Flow's scheduled paths provide a unique and powerful scheduling capability (for example, "fire 3 days before close date"). This capability includes automatic cancellation and rescheduling if the record's data changes. These automations are subject to daily limits.</td>
      <td><b>Not Available</b><br>
        An Apex trigger cannot natively schedule a temporal, record-specific event with automatic cancellation. While scheduled Apex exists, it is a fundamentally different mechanism that runs at a specific time and is not scheduled during an individual record's processing as part of a trigger.</td>
    </tr>
    <tr>
      <td><b>Ordering and choreography</b></td>
      <td><b>Available</b><br>
        The Flow Trigger Explorer allows administrators to define a relative execution order for multiple flows on the same object.</td>
      <td><b>Available</b><br>
        A trigger framework provides granular control over the exact order of automations.</td>
    </tr>
    <tr>
      <td><b>Same-record field updates</b></td>
      <td><b>Available (before save)</b><br>
        Record-Triggered Flow is the most performant declarative option for updating the triggering record before the initial DML commit.</td>
      <td><b>Available (before save)</b><br>
        Apex provides the highest performance offering with minimal overhead.</td>
    </tr>
    <tr>
      <td><b>Cross-object CRUD</b></td>
      <td><b>Available (after-save)</b><br>
        Flow is suitable for simple, low-complexity, cross-object DML operations.</td>
      <td><b>Available (after-save)</b><br>
        Apex provides superior control over deduplication, error handling, and performance for cross-object DML operations.</td>
    </tr>
    <tr>
      <td><b>Deduplication of expensive computation</b></td>
      <td><b>Available</b><br>
        Flow excels at eliminating redundant queries and DML statements via automatic bulkification. However, state cannot be cached or shared between different flow triggers or across multiple invocations of the same flow within one transaction. This limitation may become important in extreme performance scenarios.</td>
      <td><b>Recommended</b><br>
        Apex provides mechanisms for deduplicating expensive operations. Developers can leverage transactional caching using static properties and variables, and platform-level caching using Platform Cache, to store and reuse data. These techniques are important for reducing the consumption of transactional governor limits, such as SOQL queries, and ensuring high performance and scalability.</td>
    </tr>
    <tr>
      <td><b>Custom error handling</b></td>
      <td><b>Available</b><br>
        The CustomError element can block a save operation and display a message to the user.</td>
      <td><b>Recommended</b><br>
        The <code>addError()</code> method provides flexible field-level and conditional error messaging.</td>
    </tr>
  </tbody>
</table>

## Use Cases

To best emphasize how to use the decision points to guide your decisions, consider the following use cases and associated points of analysis.

### Best-Fit Recommendations

This table provides general "best-fit" recommendations for general use cases, based on the capabilities presented. Ultimately, you'll factor in additional considerations to arrive at a best fit for your particular scenarios, such as those included in the _Related Best Practices_ section of this document. There, you'll learn more about when a particular combination of Flow and Apex provides the best approach.

<table>
  <thead>
    <tr>
      <th scope="col">Use Case</th>
      <th scope="col">Description</th>
      <th scope="col" style="width:16%">Best-Fit</th>
      <th scope="col" style="width:38%">Rationale</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>High-performance batch processing</b></td>
      <td>Any automation that must process thousands of records efficiently</td>
      <td>Apex</td>
      <td>Apex provides rich APIs for interfacing with the platform and for raw speed.</td>
    </tr>
    <tr>
      <td><b>Complex data processing</b></td>
      <td>Scenarios that require advanced data manipulation</td>
      <td>Apex</td>
      <td>Apex provides data structures, such as Map and Set, that are not natively available in Flow, and can be critical for writing performant, bulk-safe code.</td>
    </tr>
    <tr>
      <td><b>Transactional control</b></td>
      <td>Control mechanisms such as savepoints, rollbacks, and partial commits</td>
      <td>Apex</td>
      <td>Apex provides access to mechanisms such as Database.savepoint and Database.rollback, and has the ability to process partially successful DML operations.</td>
    </tr>
    <tr>
      <td><b>Sophisticated custom validation</b></td>
      <td>Data validation across multiple fields in a record</td>
      <td>Apex</td>
      <td>While Flow can prevent a save with the `CustomError` element, it is not available in all flow types—including subflows. The Apex <code>addError()</code> method provides multiple field-specific error messages that can be added to a record at any time during trigger processing.</td>
    </tr>
    <tr>
      <td><b>Moderately complex logic within a simple process</b></td>
      <td>Logic and data manipulation of moderate complexity, simplified by a standard library of advanced functions, occurring as part of an uncomplicated process</td>
      <td>Flow + Apex</td>
      <td>Record-Triggered Flow acts as the orchestration layer, while high-complexity operations are encapsulated within Invocable Apex.</td>
    </tr>
    <tr>
      <td><b>Simple to moderately complex logic</b></td>
      <td>Data manipulation of low to moderate complexity, with trigger updates to both the primary and related data objects</td>
      <td>Flow</td>
      <td>Flow is typically the go-to option, as it is based on a declarative model that makes it approachable to both admins and developers.</td>
    </tr>
    <tr>
      <td><b>Notifications and outbound messages</b></td>
      <td>Sending outbound emails and messages</td>
      <td>Flow</td>
      <td>Flow makes sending email alerts and outbound messages on record changes easy and highly scalable.</td>
    </tr>
    <tr>
      <td><b>Scheduled processing</b></td>
      <td>Automation at a future, dynamic date (for example, 3 days before a close date)</td>
      <td>Flow</td>
      <td>Scheduled paths provide a unique strength to Flow, as the platform automatically handles the scheduling, cancellation, and rescheduling of these paths if the record's data changes.</td>
    </tr>
  </tbody>
</table>

### Scalable Processing: Asynchronous Use Cases in Depth

Scalability is a critical consideration when designing your implementation. When a record-triggered automation's business logic becomes complex, long-running, or involves high data volumes, the Salesforce platform's core governor limits become an architectural constraint. Operations like mass data updates, complex API callouts, or heavy computations increase the risk of breaching limits, such as total CPU time or the number of DML statements within a single database transaction. A failure in a synchronous trigger due to a limit exception will cause the user's entire save transaction to roll back, resulting in poor user experience and potential data loss. This inherent risk mandates an architectural pattern to offload complex work.

Asynchronous automation becomes essential in this case. Using asynchronous mechanisms, architects can effectively decouple the long-running or high-volume work from the primary, synchronous record-save transaction. Saves complete quickly and reliably, while the heavy processing is delegated to a separate, platform-managed transaction that executes later. Decoupling improves stability, prevents transaction failures, and is critical for building scalable enterprise applications. The platform offers several specialized tools for this, each with distinct benefits and trade-offs regarding reliability, volume, and complexity.

### Flow's Asynchronous Path

The Run Asynchronously path in a record-triggered flow provides the simplest mechanism for "fire and forget" asynchronous logic. This path executes in a separate transaction after the original record-saving transaction has been successfully committed to the database.

- **Ideal Use Case**: This is well-suited for tasks that do not require immediate execution or custom error handling. Examples include sending an email notification, creating a follow-up task, or making a simple callout to an external system.

- **Limitations**: This mechanism shares the same daily governor limits as other asynchronous flow interviews. It is not designed for extremely high-volume processing.

### Change Data Capture (CDC)

Change Data Capture (CDC) is a high‑throughput, scalable, and resilient pattern for handling asynchronous logic triggered by a record change in high‑volume scenarios. In this model, the trigger's only responsibility is to save the record synchronously. The platform then publishes a detailed event message that contains the record's changes to a high‑volume event bus. A separate, dedicated Apex trigger subscribes to this change event. It performs complex, long‑running, or asynchronous work.

- **Benefit**: This pattern decouples the asynchronous process from the initial user transaction. A failure in the asynchronous processing won't cause the user's record save to roll back. The pattern also provides a durable event stream that multiple internal subscribers or external systems can consume, and events can be replayed for up to 72 hours, providing strong resilience.

- **Limitations**: CDC event messages don't contain the record's prior state — the equivalent of an Apex `Trigger.oldMap`. The event payload includes the new field values, but not the values they changed from. This makes it challenging to implement logic based on a specific state transition (for example, run only if `Status__c` changed from "Pending" to "Approved"). You can mitigate this by querying the object's field history in the event subscriber, but this adds complexity to the process, and field history tracking may not be available for the specific field of interest. This may limit the types of automation you can offload to CDC.

By default, CDC can be enabled on a maximum of five Salesforce Objects. Organizations requiring more can purchase an add-on license that removes this limit and increases event delivery allocations.

### Queueable Apex from a Trigger

Enqueuing a Queueable Apex job directly from a trigger should be considered a risky pattern, used only when Apex-provided control is needed (for example, for complex logic or custom retry mechanisms), and CDC is not a viable option.

If Queueable Apex is required, the implementation must include proper safeguards:

- **Limit Checks**: The code must check the number of jobs already enqueued in the transaction before attempting to add another.

  ```
  if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... }
  ```

- **Context Awareness**: The code must detect if it is running within an asynchronous context, such as a batch job (`System.isBatch()`), and modify its behavior to adhere to the stricter one-job-per-transaction limit in that context.

### Limit Considerations for Triggered Asynchronous Apex

Invoking asynchronous Apex from a synchronous trigger introduces stability risks. To prevent org-level impact (for example, exceeding limits), this pattern requires rigorous design and testing.

- The daily limit for asynchronous Apex executions (`Batch`, `Queueable`, `@Future`) is shared across the org (typically 250,000 or a calculation based on user licenses). A bulk data load of 20,000 records will cause a trigger to execute in chunks of 200, resulting in 100 separate trigger invocations — even more if the bulk batch size is fewer than 200 records. If each invocation enqueues an asynchronous job, a significant portion of the daily limit from a single data load may be consumed. This consumption can potentially starve other critical business processes of async resources.

- The governor limits for enqueuing jobs are drastically different depending on the context. From a trigger fired by a user action in the UI — a _synchronous_ transaction — up to 50 queueable jobs can be enqueued. However, from a trigger fired within the `execute` method of a Batch Apex class — an _asynchronous_ transaction — only one queueable job can be enqueued. Failing to account for this difference is a common and critical failure point, leading to `LimitException` errors during large data operations.

- Calling Schedulable Apex (`System.schedule`) or Batch Apex (`Database.executeBatch`) directly from a trigger context constitutes an anti-pattern. These methods are not designed to be invoked from trigger context. Doing so will lead to rapid consumption of your asynchronous Apex allocation, resulting in limit exceptions.

### Choosing the Right Asynchronous Pattern

Each asynchronous mechanism has specific trade-offs regarding performance, governor limits, and reliability. Use this decision tree as a guide to help you navigate these options and choose the right mechanism for your use case.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="Asynchronous pattern decision tree">

### The Scheduled Job Alternative

As the flowchart indicates, when you are faced with high-volume DML operations but cannot use Change Data Capture (perhaps due to object limits), the best architectural choice is often to avoid a trigger-invoked process entirely.

Instead, consider using a scheduled process. This can be either a Scheduled Flow or Scheduled Apex. Required steps are:

1. Perform a simple, low‑cost update in the synchronous trigger. For example, set a `Status__c` field to "pending processing" or insert a low‑cost related record, such as a Chatter post, to indicate that the record needs processing.

2. Create a scheduled job, either a scheduled flow or scheduled Apex, that runs periodically, such as every 15 minutes or every hour.

3. Have the scheduled job query for all records in the pending state, execute the complex logic in a controlled, high-volume context, and then update the records as processed.

This pattern fully decouples the heavy processing from the user's synchronous save, is not subject to the one-job-per-transaction limit of a trigger-fired batch, and provides a highly scalable and governable solution for non-real-time requirements.

If the latency of a scheduled job is not acceptable for the business requirements, and you are still constrained from using CDC or a trigger-fired queueable, this indicates a significant architectural mismatch. At this point, different mechanisms must be considered. Reevaluating the core application design may lead to certain conclusions, such as:

- Purchasing the add-on to remove CDC object limits.

- Fundamentally challenging the business requirement to determine if near real-time processing is truly a "must-have" or if the latency of a scheduled job is an acceptable trade-off for platform stability.

## Non-Functional Considerations

In addition to the decision points, you will need to factor in non-functional considerations such as complexity and standards.

### Complexity

The level of complexity in an implementation is part of a solution's total cost of ownership, as well as its ability to adapt to changing business requirements. Complexity can impact any implementation if best practices aren't followed. In the _Related Best Practices_ section of this document, there are recommendations to reduce the amount of complexity in your solution, including these patterns:

- Hybrid Pattern: Invocable Apex for Complex Logic in Flow

- Using a Metadata Framework for Apex Triggers

- Mega-Flows vs. Multiple Flows

### Processes and Standards

Documentation is as important as the automation itself. It not only ensures maintainability, it is also critical for AI and agent-based tools. Documentation helps you understand and manage your business processes.

**In Flow**

- Establish a consistent naming convention for all elements and variables.

- Use the Description field for the flow to explain its overall purpose, trigger criteria, and intended outcome.

- Use the Description field on each individual element (for example, `Get Records`, `Action`, `Transform`). This practice is the best way to convey intent. It's especially important for invocable actions and subflows, where the description is the primary place to explain the complex logic performed by the action.

**In Apex**

- Comment your code clearly to explain the _why_ behind your logic, not just the _what_.

- If using a metadata-driven framework, ensure your metadata records include and populate a human-readable Description field to explain what each handler class does and when it should run.

DevOps and source control is part of a mature development lifecycle. Always use a source control tool like Git for Salesforce projects. Both Apex classes and Salesforce Flows are metadata that define your business logic, and they must be versioned and managed.

Within the context of management of record-triggered automations, a modern DevOps pipeline provides essential benefits.

- **Automated Quality Checks:** Tools like [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) can be configured to run automatically in your pipeline. Static analysis can detect problematic patterns in both automation tools before they are promoted, flagging issues like inefficient `Get Records` elements inside a Flow loop or `SOQL` queries inside an Apex for loop, which are common causes of performance degradation.

- **Regression Prevention:** As your automation density grows, a change to one Flow or Apex class can have unintended consequences for other automations on the same object. A robust DevOps testing strategy, where automated Apex tests are run against any proposed change, is the most reliable way to ensure a new Flow version doesn't break existing Apex logic (and vice versa).

- **Collaboration and Visibility:** Source control is the "single source of truth." It allows admins and developers to work on automation for the same object in parallel. It also provides an invaluable audit trail: when a production process breaks, you can instantly see _who_ changed the automation, _when_ they changed it, and — via commit messages — _why_ they changed it.

For teams with a mix of admins and developers, [DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) provides a unified interface to help choreograph all of these steps, making a scalable, source-control-based development process accessible to everyone on the team.

This combined discipline of documentation and DevOps ensures the long-term health and maintainability of your org, which will benefit every architect and admin who follows you.

## Related Best Practices

The decision guide above is best used before planning your implementation. It is targeted at helping you choose the best product for your use cases. After product selection, it is important to understand existing best practices for your implementation.

### Exploit the Hybrid Pattern: Invocable Apex for Complex Logic in Flow

The _One Tool Per Object_ principle is critical for managing high-density automation, but don't interpret it as a binary choice between a purely declarative or a purely programmatic stack. A more effective and maintainable architectural pattern leverages a Hybrid model: position Record-Triggered Flow as the orchestration layer, while encapsulating high-complexity operations within Invocable Apex.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="Hybrid pattern diagram">

#### The Orchestration Layer: Flow

Record-Triggered Flow serves as the orchestrating layer for the business process. It owns the entry criteria and execution context (the _what_ and _when_). By retaining decision logic and routing within this layer, the architecture's process topology remains transparent and manageable via the Flow Trigger Explorer, preventing critical business logic from being obscured within code.

#### The Complex Component: Invocable Apex

One common example of a complex component is the implementation of Service Level Agreement (SLA) calculations for Case records. Since the BusinessHours object and its related logic — critical for accurate calculations that exclude non-working hours and holidays — is not natively accessible in Flow, a dedicated Apex class is used. This class, often named something like `ServiceLevelAgreementCalculator`, is designed with a single static method, annotated with `@InvocableMethod`, to calculate the elapsed business hours, determine if the SLA is "Within Target" or "Breached," and return a structured output. This approach encapsulates the complex, high-performance logic in Apex while allowing it to be seamlessly executed and integrated into the declarative orchestration layer of a record-triggered flow.

Once the Apex `ServiceLevelAgreementCalculator` class is defined, it's available for use within a record-triggered flow:

This pattern demonstrates a strict separation of concerns. The declarative layer is used to manage the transaction lifecycle and orchestration while code is used for high-complexity execution. By treating code as a functional utility rather than the foundation, we balance performance and maintainability.

#### Key Gains with the Hybrid Pattern

**Modularity**: The decision pivots away from the singularity of using Apex or Flow for the entire process. Instead, the architecture encapsulates complex logic into discrete, bulk-safe, and independently testable units. These units function as reusable components consumed by the declarative layer, ensuring the automation scales without complicating the architectural design.

**Reusability**: Logic is decoupled from the trigger event. A well‑designed code unit (such as an `InvocableMethod`) is written one time but leveraged across multiple entry points: Record-triggered flows, screen flows, or external integrations. This code reuse eliminates redundant development.

**Maintainability**: The process flow logic remains visible and manageable within the declarative Flow. This centralization drastically reduces debugging overhead and ensures that the system's execution order is deterministic and transparent.

#### Limitations and Trade-Offs of the Hybrid Pattern

While the hybrid model of using invocable Apex from Flow is powerful, it is not a one-size-fits-all approach. Architects must be aware of the specific limitations and trade-offs before committing to a hybrid solution.

- **No before-save support**: This is the most critical limitation. Invocable Actions are only available in the after-save context (flows for actions and related records). They cannot be used in the high-performance before-save context (flows for fast-field updates). Therefore, this pattern cannot be used to delegate same-record field updates. Do that high‑performance work using native Flow elements in a before-save flow or within a before‑context Apex trigger.

- **No after-undelete support:** Record-Triggered Flow currently does not support the after-undelete context. If a Salesforce Object has a business requirement to run automation when a record is restored from the recycle bin, an Apex trigger is the only solution.

- **Performance overhead in high-volume scenarios:** The transition from the Flow runtime to the Apex runtime is not a zero-cost operation. While generally fast, the act of dropping into an Invocable Action from Flow's runtime is not as computationally fast as native execution that stays entirely within an Apex trigger. For most medium-density automations, this micro-overhead is a negligible and worthwhile trade-off for the increased accessibility. However, for extreme high-performance, high-volume scenarios, a pure Apex-only framework will have a raw compute speed advantage.

### Strategies for Legacy Automation

While the automation density heuristic provides definitive guidance for newer greenfield architecture, the reality of enterprise Salesforce environments is often more nuanced. In mature orgs, it is common to find record-triggered flows and Apex triggers operating on the same Salesforce Object. This scenario is distinct from the hybrid pattern explained earlier: here, the flows and Apex triggers are not coupled nor designed to work together.

This coexistence is often a result of evolving platform capabilities or legacy technical debt. While this is a tolerated operational state, architects must treat it as a calculated trade-off rather than an end state.

The fragmented orchestration causes significant governance and maintenance overhead, making development, testing, and incident handling activities disjointed and cumbersome. This leads to increased Time to Resolution (TTR) and operational complexity.

- For new Salesforce Objects, adhere to the automation density principle as the primary guide.

- For existing Salesforce Objects with a hybrid footprint and dual apex trigger and record-triggered flow entry points, assess the density and then architect to refactor to a maintainable hybrid state.

  - For low density, refactor Apex triggers to record-triggered flows, and specify order of execution, bringing them to a single automation entry point.

  - For medium density, refactor complex mega-flows into a subset of flows, with the right order of execution. Introduce Apex triggers only when absolutely necessary, for example to support after undelete context.

  - For high density, favor implementing Apex triggers.

### Using a Metadata Framework for Apex Triggers

As an organization's business processes on the Salesforce platform mature, the volume and complexity of record-triggered automation inevitably increase. A foundational best practice is to maintain _one Apex trigger per Salesforce Object_. This rule is critical because the platform does not guarantee the execution order of multiple triggers on the same object for the same event. This limitation can lead to non-deterministic behavior, race conditions, and difficult-to-debug issues.

However, adhering to the _one trigger_ principle introduces an architectural challenge: how to manage and orchestrate all the business logic invoked from that single entry point in a maintainable, scalable way.

#### The Limitations of Classic Trigger Handlers

The first evolution of this architecture was the Classic Trigger Handler pattern. In this approach, the single Apex trigger delegates all its logic to a corresponding handler class (for example, `OpportunityTriggerHandler`). This method separates the logic from the trigger file and provides developers with deterministic control over the order of execution within the handler class's methods (for example, `afterInsert()`).

While an improvement, this pattern often leads to monolithic handler classes. Over time, as more business requirements are added, the class becomes large, difficult to manage, and hard to test in isolation. The execution order of all individual processes is hard-coded within a single method, making the class prone to merge conflicts, dramatically increasing the governance and maintenance overhead in a large enterprise environment.

#### The Solution: A Metadata-Driven Trigger Framework

To resolve the core issues of modularity and orchestration, architects shift to a **Metadata-Driven Trigger Framework**. This is a significant architectural leap that decouples the automation logic itself from the configuration of _how_ and _when_ it runs.

This framework is built on three key advantages:

- **Partitioning:** Instead of a single handler class, the core business logic is broken down into small, atomic Apex classes (for example, a `RecalculateAccountValues` class or a `NotifySalesLeads` class), with each class adhering to the _Single Responsibility Principle_. This modularity makes logic easier to test, debug, and understand in isolation.

- **Order and choreography:** The execution order is no longer hard-coded in Apex. Instead, it is declaratively defined by configuration records, typically stored in a custom metadata type (for example, `TriggerAction__mdt`). This allows administrators to re-order, add, or remove automation actions simply by modifying a metadata record, which does not require a deployment or code change.

- **Bypass functionality:** The framework provides standardized, granular bypass functionality. Each automation action can be configured via its metadata record to be turned off globally, or bypassed for specific administrative users by referencing a custom permission.

The single Apex trigger for the object then serves only as a dynamic dispatcher. It contains no business logic, but instead instantiates a central `MetadataTriggerHandler` class. This handler queries the custom metadata records to dynamically determine the execution sequence and invoke the correct atomic Apex classes in the prescribed order. Automation is unified under a single, transparent, and governable layer.

### Deduplicating Expensive Operations in the Transaction

An important benefit of using Apex in a robust framework is the ability to manage transactional state and optimize performance by eliminating redundant work. As logic accumulates, it's common for different automations within the save order to independently execute the same expensive operations, consuming valuable governor limits and increasing the DML operation time.

The framework is architected to address this with two primary strategies:

- **Shared state management:** Within the scope of a single Apex transaction, static properties and variables are leveraged to cache data. This ensures that an expensive operation, like a `SOQL` query for a configuration setting, only executes once, even if the automation logic is invoked multiple times across different records or phases of the trigger. Consumption of transactional limits is significantly reduced.

- **Platform cache utilization:** To go beyond simple intra-transaction caching, use the platform cache to avoid querying the entire database for certain data. This managed, in-memory cache is ideal for retrieving data that is non-primitive, read frequently across the codebase, and immutable throughout the course of a transaction (for example, profiles, roles, business hours). Using the `Cache.CacheBuilder` interface, the system checks the cache first and only performs the database query if the data is not present, maximizing performance and scalability.

### Use Before-Save for Same-Record Updates

Always use a before-save update when your automation only needs to change field values on the record that starts the transaction. This applies to both fast-field updates in Flow (which run before save) and before-context logic in Apex Triggers (before insert, before update).

This pattern is performant, regardless of which tool is used, because it avoids a second DML operation and a recursive save cycle. The changes are made to the record in memory _before_ it is committed to the database, and are saved as part of the original transaction. The overhead of a second save, which would otherwise re-execute the entire save order and fire all automation again, is eliminated.

### Preventing Uncontrolled Recursion

Uncontrolled recursion is a common pitfall in after-update triggers, where a trigger's logic performs a DML update that in turn causes the same trigger to fire again. This creates an infinite loop that eventually terminates with a governor limit exception. While static boolean flags or collections of processed record Ids have historically been used to prevent such recursion, a more precise and robust pattern is to gate the logic by comparing field values between the new and old versions of the record itself.

Execute the logic only if a specific field of interest has actually changed. This prevents the trigger from running its logic on subsequent DML operations within the same transaction where the critical data remains unchanged.

#### Controlling Recursion in Record-Triggered Flow

In a record-triggered flow, prevent uncontrolled recursion by setting the flow to run only when the record is updated to meet the condition requirements:

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="Controlling recursion in Record-Triggered Flow">

If you choose to use an entry criteria formula in your flow, you can prevent runaway recursion by comparing the `$Record` global variable (representing the new values) with the `$RecordPrior` global variable (representing the original values before the save). For example, to ensure that a flow only runs if the Amount field on an Opportunity has changed, use this in the entry criteria:

```
$Record.Amount != $Record__Prior.Amount
```

#### Controlling Recursion in Apex

Compare field values from the new version of the record, `Trigger.new`, with the field values from the old version of the record, `Trigger.oldMap`, to see if the specific change you're looking for has occurred. This approach makes sure that the automation is idempotent and only runs when necessary, making the system more efficient and preventing catastrophic recursive loops.

### Bypassing Automation

A well-architected Salesforce organization requires a consistent and reliable mechanism to bypass automation. This is not an optional feature, but a core operational requirement for maintaining data integrity and enabling administrative tasks.

A bypass framework is essential for some scenarios:

- When loading large volumes of data, firing triggers for every record can drastically slow down the process, cause limit exceptions, and create erroneous related records and notifications. A bypass allows the data to be inserted cleanly and efficiently.

- An integration user may need to synchronize data from an external system of record. The automation that normally fires for a user-initiated change (for example, sending an email, creating a task) may be undesirable or redundant when the change originates from another system.

- Administrators or support staff may need to perform corrective updates on records. A bypass mechanism allows them to make these changes without triggering the standard business automation, which could have unintended consequences.

**Custom permissions**: The modern, scalable standard for implementing bypass logic is custom permissions. These are superior to older methods for several reasons:

- **Flexibility:** Custom permissions can be assigned to users via permission sets. This practice aligns with the modern Salesforce security and access model, allowing for granular and flexible assignment. A bypass can be granted to a specific user, or even temporarily with a specific expiration date/time.

- **Maintainability:** Using custom permissions avoids hard coding profiles or users into automation logic. If a user's role changes or a new profile needs bypass access, the change is a simple Permission Set assignment, not a code or flow modification that requires a deployment.

- **Scalability:** Custom permissions provide a scalable framework for managing exceptions across a complex user base. They can be assigned to users via permission set, permission set groups, or profiles. Their association to a permission set or profile is also representable in source metadata.

**Implementation patterns**: Apply a consistent bypass pattern to all record-triggered automation in the organization.

**Bypassing a record-triggered flow**: The most efficient way to bypass a flow is to prevent it from running at all. This is achieved by adding a condition to the flow's entry criteria.

- In the Start element of the record-triggered flow, set the Condition Requirements to Formula Evaluates to True.

  - In the formula builder, incorporate a check for the custom permission using the `$Permission` global variable. Combine the check with your existing entry criteria.

    - Formula pattern:

    ```
    ( ) && NOT($Permission.Bypass_This_Flow)
    ```

  - This pattern ensures that the flow only runs if the user _does not_ have the specified custom permission assigned. This check is performed before the flow interview is even created, making it the most performant approach.

**Bypassing an Apex Trigger Framework**: In Apex, integrate the bypass logic directly into the metadata-driven trigger framework, allowing for granular control.

- The `TriggerAction__mdt` custom metadata type should include a text field, for example, `BypassPermission__c`.

  - In the `MetadataTriggerHandler` class, before dynamically executing an action, the code should read the value from this field.

  - If the field is populated, the handler uses the `FeatureManagement.checkPermission()` method to determine if the current running user has the specified custom permission.

  - If `checkPermission()` returns true, the handler skips that specific action and proceeds to the next one in the sequence.

  - This pattern is powerful because it allows for both a global bypass (if all `TriggerAction__mdt` records reference the same permission) and a granular per-action bypass (if different records reference different permissions, or some have no bypass permission at all).

### Mega-Flows vs. Multiple Flows

It is an anti-pattern to consolidate all of an object's automation into a single, massive mega-flow. Consolidating into one flow versus splitting logic into multiple, well-conditioned flows does not have a major impact on performance. The most significant performance gains come from:

- Using before-save flows for same-record field updates.

- Writing precise entry conditions to ensure flows are excluded from running on changes that do not impact their specific use case.

[Flow Trigger Explorer](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) allows you to assign an order value to each flow on an object, guaranteeing a sequential execution order.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="Flow Trigger Explorer">

## Resources

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">Flow</th>
      <th scope="col">Operations</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">What is Apex?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Apex Utilities</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">About Automation with Salesforce Flow</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">Meet Flow Trigger Explorer</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Flow Transform Element</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Salesforce Code Analyzer</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>