Process Automation Settings
Process Automation Settings is a Setup page in Salesforce where an administrator configures org-wide options that apply to the automation engine.
Definition
Process Automation Settings is a Setup page in Salesforce where an administrator configures org-wide options that apply to the automation engine. The page is small, but the handful of fields on it shape how Flow, the retired Process Builder, and the older Workflow Rules behave across the whole org. It covers who appears as the running user when a triggering user is inactive, who receives error emails, and whether people can pause flow interviews.
You reach it from Setup by typing Process Automation Settings into the Quick Find box. Most teams set these values once during initial setup and then revisit them only when automation reporting or error handling needs a change. The settings sit underneath every individual automation, so a wrong choice here can quietly affect debugging and audit trails everywhere.
What lives on the Process Automation Settings page
The Default Workflow User and why it exists
The Default Workflow User is a lookup field that names one user as a fallback identity for automation. When a time-based action fires after the person who triggered it has gone inactive, Salesforce needs a valid, active user to attribute the action to. That fallback is the Default Workflow User. The same user is shown on a workflow rule when the triggering user is no longer active. If your org uses time-dependent workflow actions, designating a Default Workflow User is required, not optional. When a problem occurs with a pending action, this user also receives an email notification. Pick a dedicated, permanently active service account here rather than a real employee. People leave, and a deactivated Default Workflow User causes pending actions and audit entries to look broken or stall. A service account keeps attribution stable for years. Document who the account is and why it was chosen, because the name surfaces in record history and confuses future admins who do not know its purpose. This one field has an outsized effect on how trustworthy your automation audit trail looks.
Choosing who gets flow and process error emails
When a flow or process hits an unhandled fault, Salesforce sends an error email. The Send Process or Flow Error Email To setting decides where that email goes. There are two choices. The default is User Who Last Modified the Process or Flow. With that option, the email lands with whoever saved the automation most recently, which is often the builder. The second option is Apex Exception Email Recipients. That points error emails at the list of users maintained on the Apex Exception Email page in Setup. The practical difference is reliability. A single builder might be on leave, might have left the company, or might not monitor their inbox. A curated recipient list means a team sees the failure regardless of who touched the automation last. For any org running business-critical automation, switching to Apex Exception Email Recipients is the safer default. It separates the alerting audience from whoever happened to edit the flow. Pair the setting with fault paths inside individual flows, because the org-wide email is a safety net, not a substitute for designed error handling on the flows that matter most.
Letting users pause flow interviews
The Let Users Pause Flows checkbox controls one runtime behavior. A flow interview is a single run of a flow for one user. When a screen flow contains a Pause element, the running user can stop partway through and come back later. That stop-and-resume capability only works if this org-wide checkbox is enabled. Turn it on when you build screen flows that span long tasks, gather information people cannot supply in one sitting, or wait on an external step. The paused interview is saved, and the user resumes it from where they left off. Leave the box unchecked and Pause elements have nothing to act on, so a flow that relies on pausing simply cannot offer it. This is a good example of how a single org-wide toggle gates a feature you design at the individual flow level. Builders sometimes spend time debugging why a Pause element does nothing, when the real fix is one checkbox on this Setup page. Review the setting before you ship any flow that depends on pausing, so the runtime behavior matches what you designed.
How these settings reach across the automation tools
The settings on this page are platform-level. They do not belong to one flow or one rule. They tune the engine that runs Flow, the retired Process Builder, and the older Workflow Rules together. That shared scope is exactly why the page deserves a deliberate pass during setup, even though it has few fields. Consider attribution. The Default Workflow User can appear in record history for actions across all three tools, so one careless choice muddies audit trails everywhere at once. Consider alerting. The error email recipient applies to flows and processes broadly, so getting it wrong means failures across many automations route to the wrong inbox. Because the effects are wide, the cost of revisiting is low and the cost of ignoring is high. A five-minute review prevents weeks of confusing reports later. Treat this page like a configuration checklist item rather than something you stumble into while debugging. Set the values on purpose, write down the reasoning, and confirm them again whenever you inherit an org or stand up a new one. The reward is automation whose behavior you can actually explain.
Email From address and the Automated Process User
Automation often sends email on its own, and the From address on that email matters for deliverability and trust. Salesforce lets you send email from automation using a verified organization-wide email address rather than a generic system identity. You define organization-wide addresses separately, under Organization-Wide Addresses in Setup, then choose one for automated sending. Without a verified org-wide address, automated email can go out from an address recipients do not recognize, which hurts open rates and can trip spam filters. With one configured, flows and the Automated Process User can send from a consistent, branded, verified address your customers expect. This is closely related to Process Automation Settings because both shape how automation presents itself to the outside world and to your own audit trail. One controls the identity attached to actions and errors, the other controls the identity attached to outbound mail. Treat them as a pair when you plan an org. Verify the address, confirm who is allowed to use it, and test a real send before you depend on it. Small upfront effort here avoids embarrassing From addresses in production email.
Currency note: Workflow Rules support has ended
One reason this page reads like a relic in places is that two of the three tools it governs are no longer the path forward. Support and updates for Workflow Rules ended on December 31, 2025, meaning bugs in that product are no longer fixed. Process Builder is retired as well. Flow is the supported automation tool going forward. The Process Automation Settings page itself remains in Setup and still matters, because its fields apply to Flow too. The Default Workflow User still backstops time-based work, the error email recipient still routes flow faults, and the pause checkbox still gates screen-flow pausing. What changes is your mental model. Do not invest in new Workflow Rules or Process Builder definitions. If you inherit an org leaning on them, plan a migration to Flow and use Salesforce's migration tooling where it helps. Meanwhile, keep these org-wide settings correct, because Flow inherits them. The lesson is that platform settings outlive individual tools. A page built in the Workflow era now serves the Flow era with barely any change, so understanding it stays worthwhile.
How to configure Process Automation Settings
Configure the org-wide automation options once, deliberately, ideally during initial org setup. You need the Customize Application permission. The page applies to Flow and to the retired Workflow Rules and Process Builder, so changes here affect every automation in the org.
- Open the settings page
From Setup, type Process Automation Settings into the Quick Find box and select it. The full page of org-wide options opens.
- Set the Default Workflow User
Use the lookup to pick a permanently active service account. This is required if you use time-dependent workflow actions, and it backstops attribution when triggering users go inactive.
- Route error emails
Set Send Process or Flow Error Email To. Choose Apex Exception Email Recipients for a monitored team list, instead of the lone user who last edited the automation.
- Decide on pausing
Enable Let Users Pause Flows if any screen flow uses a Pause element. Leave it off otherwise. Then save the page.
Lookup naming the fallback identity shown when a triggering user is inactive; required for time-dependent actions and used for pending-action alerts.
Picks the error-email audience: User Who Last Modified the Process or Flow (default), or Apex Exception Email Recipients (a curated list).
Org-wide checkbox that enables the Pause element in screen flows so a running interview can stop and resume later.
- Pointing the Default Workflow User at a real employee breaks audit trails and pending actions the moment that person is deactivated.
- Leaving error emails on the last-modified user means failures can route to someone on leave or no longer at the company.
- A Pause element does nothing if Let Users Pause Flows is unchecked, which sends builders chasing a non-existent flow bug.
Prefer this walkthrough as its own page? How to Process Automation Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Process Automation SettingsSalesforce
- Identify Your Salesforce Org's Default Workflow UserSalesforce
Straight from the source - Salesforce's reference material on Process Automation Settings.
- Select Flow and Process Error Email RecipientsSalesforce
- Let Users Pause Flow InterviewsSalesforce
Hands-on resources to go deeper on Process Automation Settings.
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 the Process Automation Settings page configure in Salesforce?
Q2. Why does the Default Workflow User setting matter for audit trails?
Q3. Which automation tools are affected by Process Automation Settings?
Discussion
Loading discussion…