Automation App
An Automation App in Salesforce is a focused app or Setup surface dedicated to building, scheduling, and monitoring the automation that runs behind the scenes.
Definition
An Automation App in Salesforce is a focused app or Setup surface dedicated to building, scheduling, and monitoring the automation that runs behind the scenes. The label is not one fixed product. It points to whichever surface a given cloud uses to house its automation, and the meaning shifts with context. In the core CRM platform it usually means the Flow Builder surface and the supporting Setup pages under Process Automation. In Marketing Cloud Engagement it means Automation Studio, the tool that orchestrates data imports, SQL queries, file transfers, and scheduled sends.
The common thread is a single place where automation lives, gets watched, and gets debugged. For most CRM admins working in 2026 the relevant Automation App is Flow Builder plus its monitoring views, because Salesforce stopped supporting Workflow Rules and Process Builder on December 31, 2025. For Marketing Cloud teams the relevant Automation App is Automation Studio, which stays the home for data preparation and back office messaging workflows. Both describe a contained workspace where automation is created, governed, and observed.
How the Automation App splits across Salesforce clouds
The CRM Process Automation surface
In the core CRM platform, automation is gathered under Setup, in the Process Automation section. The pages there cover Flow, Process Builder, Approval Processes, and related settings. This grouping is the closest thing to a single Automation App for a Salesforce admin. You do not launch one branded application called Automation App. You open Setup and move between the list views that each automation type provides. Flow Builder is the modern tool that Salesforce points every new build toward. The other entries are either legacy or supporting pieces. Approval Processes remain actively supported and still appear here. Workflow Rules are no longer supported, and Process Builder sits in the same end of support bucket. The practical effect is that an admin spends most of their automation time in the Flows list and in Flow Builder itself. The surrounding pages exist for older automation that has not been migrated yet, and for the approval logic that has not moved to Flow. Treating Process Automation as one coordinated workspace, rather than a pile of unrelated screens, is what makes governance tractable.
Flow Builder as the modern centre
Flow Builder is where almost all new declarative automation is built today. Setup, then Flows, lists every Flow in the org with its status, trigger type, version number, and last modified date. From that list you open Flow Builder to design record triggered flows, screen flows, scheduled flows, and autolaunched flows. Salesforce describes Flow Builder as a low code tool for creating simple or complex automation with little or no code. The point of consolidating around it is that one tool now covers the work that used to be spread across Workflow Rules, Process Builder, and parts of Approvals. Monitoring sits right next to building. Paused Flow Interviews shows flows that are waiting, and a failed interviews view surfaces flows that errored. Each Flow also keeps its own run detail so you can trace what happened on a specific record. Together the Flows list and these monitoring views form the operational Automation App for CRM admins. When people on a CRM team say they live in the Automation App, this Flow centred set of screens is almost always what they mean in 2026.
Marketing Cloud Automation Studio
Marketing Cloud Engagement ships Automation Studio as its dedicated Automation App. Salesforce defines it as a tool for automating email sends, queries, imports, and more by building simple or complex workflows based on criteria you configure. The activities you drag into an automation include SQL Query for unifying data across data extensions, Data Extract for producing files to use outside Marketing Cloud, File Transfer for moving and decrypting files on the enhanced FTP, Import File for loading datasets, Filter for segmentation, Send Email, Script for server side JavaScript, Wait for timing, and Verification for guarding against bad data. An automation can be scheduled to run on a timetable or triggered when a file lands on the FTP. This is where most production data preparation in Marketing Cloud actually runs. Journey Builder handles the customer facing orchestration, but the data refreshes and back office jobs that feed those journeys usually live in Automation Studio. The overview page shows automation statuses, run history, and lets you pause, skip, or stop runs. That makes it a complete build and monitor surface in its own right, separate from anything on the CRM side.
Monitoring and observability
Every Automation App includes views for watching what ran and what broke. On the CRM side the key surfaces are the failed flow interviews view, the paused flow interviews view, and the run history kept per individual Flow. These tell you when a record triggered flow errored, which interviews are waiting on a pause or a scheduled resume, and what a flow did step by step on a given record. In Marketing Cloud the equivalent is the activity history inside each automation plus the Automation Studio overview dashboards, which report status and recent runs. The native retention on these views is limited, so production teams often build their own dashboards and reports on top of the underlying objects. Doing so extends how far back you can look and lets you add custom indicators, such as failure rate by automation or average run duration. The discipline that separates a calm operation from a noisy one is setting up this monitoring before automation becomes business critical. A silent failure that nobody sees for a week is far more expensive than the few hours it takes to build the dashboard that would have caught it on day one.
Packaged Automation Apps from ISVs
Some AppExchange products ship their own Automation App as part of a managed package. After you install the package, its app appears in the App Launcher with its own tabs, its own bundled Flows, its own scheduled jobs, and sometimes its own monitoring screens. This pattern shows up often in revenue operations tooling, in CPQ and billing extensions, and in field service add ons. The package vendor builds and maintains the automation, and you configure it through the settings the app exposes rather than editing the underlying Flows directly. That arrangement has a trade off worth understanding. You get automation that the vendor supports and upgrades, but you also inherit a surface your team did not design and may not fully see into. When a packaged automation misbehaves, you often debug it through the vendor app rather than the standard Flows list, because the managed components can be locked. Knowing which automation in your org is yours and which belongs to an installed package is part of keeping the overall picture clear. It also matters for permissions, since a packaged app frequently asks for its own permission set rather than reusing the standard automation permissions.
The migration trend toward Flow
Salesforce has been steadily consolidating CRM automation around Flow. Workflow Rules and Process Builder reached end of support on December 31, 2025. After that date Salesforce confirms they may keep running existing automation, but customer support is not available and bugs will not be fixed. The official guidance is to migrate that automation to Flow Builder, described as a modern, extensible, low code solution. Salesforce ships a Migrate to Flow tool to help convert eligible Workflow Rules and Process Builder logic rather than rewriting it by hand. Approval Processes are a separate story. They remain actively supported and are not part of the end of support change, although Salesforce has signalled a longer term direction of building approvals with Flow. The takeaway for anyone managing an Automation App is that the surface keeps shrinking toward a single tool. Older entries on the Process Automation page exist mainly to host automation that has not been moved yet. Planning that move early matters, because the conversion can take real time and testing in a complex org, and running unsupported automation indefinitely is a risk that compounds quietly.
Permissions and governance
Access to an Automation App is controlled by permissions, and getting those right is the cheapest governance you can buy. On the CRM side, building and editing Flows requires the Manage Flows permission, and related metadata work often needs Customize Application. Process Builder work used the Manage Process Builder permission. Granting these to admins, and only to admins, keeps automation predictable and stops well meaning users from creating shadow automation that nobody tracks. Marketing Cloud Automation Studio uses its own roles and permissions inside the Marketing Cloud user model, which is wholly separate from CRM profiles and permission sets. That separation is easy to forget when one person owns both, and it means cross cloud governance has to be set up deliberately rather than assumed. Beyond raw access, the governance habits that pay off are naming conventions, documented ownership for each automation, and a clear rule about which tool new work should use. Three failure patterns recur. Treating each automation type as an unrelated island produces sprawl. Skipping the monitoring views leaves failures invisible. And not training admins on the full scope of the Automation App lets automation accumulate without anyone owning the whole.
Trust & references
Cross-checked against the following references.
- Automation StudioSalesforce
- Salesforce Workflow Rules and Process Builder End of SupportSalesforce
Straight from the source - Salesforce's reference material on Automation App.
- Automate Tasks with FlowsSalesforce
- Automation Studio ActivitiesSalesforce
Hands-on resources to go deeper on Automation App.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Automation App represent in the Salesforce Platform?
Q2. How does Salesforce's multi-tenant model affect Automation App?
Q3. Who can benefit from understanding Automation App?
Discussion
Loading discussion…