Initial Submission Actions
An Initial Submission Action is an automated action that fires the moment a record first enters a Salesforce Approval Process.
Definition
An Initial Submission Action is an automated action that fires the moment a record first enters a Salesforce Approval Process. It runs when a user clicks Submit for Approval, the record meets the entry criteria, and the request is created, before the first approver ever sees it. The default Initial Submission Action locks the record so that nobody except approvers and administrators can edit it while the approval is pending. On top of that lock, an admin can attach field updates, email alerts, tasks, outbound messages, and flows.
This phase belongs to the Classic Approval Process model, where Initial Submission Actions sit next to Final Approval Actions, Final Rejection Actions, and Recall Actions. Each phase is a hook into a different point of the approval lifecycle. Initial Submission is the one almost every process uses, because it sets the opening state of the record. A typical setup stamps an Approval Status field, emails the first approver, and posts a confirmation so the submitter and the reviewer see the same picture from the first second the request exists.
How the submission phase shapes the whole approval
Where Initial Submission sits among the four action phases
A Classic Approval Process exposes four sets of automated actions, and each one maps to a moment in the record lifecycle. Initial Submission Actions fire when the record is first submitted. Final Approval Actions fire when the last required approver says yes. Final Rejection Actions fire when any approver rejects the request. Recall Actions fire when the submitter pulls the request back before a decision. Every phase can run the same menu of action types, so the difference is purely about timing. Initial Submission is the busiest phase in most builds, because it has to prepare the record for review. It is also the only phase that ships with a built-in action you cannot remove: the record lock. Admins layer their own actions on top of that lock to communicate the new state. Thinking of the four phases as a state machine helps a lot. Submission opens the case, approval and rejection close it two different ways, and recall resets it. When you design one phase, sketch the other three at the same time so the record never ends up in a half-finished state, like locked with no approver notified.
The record lock you get for free
Every Classic Approval Process locks the record automatically at initial submission. While the record is locked, only assigned approvers and users with the Modify All Data permission can edit it. The point is integrity. If a submitter could keep editing a discount, a contract, or an expense after submitting it, the approver might approve one version and get another. The lock freezes the record at the values the approver actually reviews. You control who can edit a locked record on the approval process itself, through the Record Editability setting. The two choices are Administrators only, or Administrators and the currently assigned approver. Changing that setting only affects records submitted after you save it, so existing in-flight approvals keep their original behavior. The lock is released when the process finishes through final approval, final rejection, or recall, and you can also unlock records with the Apex Approval.unlock method or a flow. Because the lock is implicit, new admins sometimes forget it exists and chase a phantom bug when a submitted record refuses to save. The first thing to check on a locked record is whether it is sitting in an open approval.
Field updates that set the opening state
The most useful custom Initial Submission Action is a field update that stamps a visible status. A common pattern creates an Approval Status picklist on the object and sets it to Pending or Submitted the instant the request opens. That single value does a lot of work downstream. Reports and dashboards can now filter for in-flight approvals, so a manager can see everything waiting on a decision. List views can color or group records by status. Other automation, such as a record-triggered flow, can react to the status change and do extra work, like notifying a finance queue. Field updates at this phase can also blank or default helper fields, for example clearing an old rejection reason so it does not linger on the new attempt. Keep these updates lightweight. A field update on submission counts toward the same governor and recursion rules as any other field update, and it can re-trigger workflow rules or flows that watch the same field. The Trailhead discount-approval project shows the canonical version of this action, an update named Approval Status Pending that flips the status field to Pending the moment a discount is submitted.
Email alerts that push the request to the approver
The second action almost every process needs is an email alert to the first approver. Without it, an approver only learns about a pending request by spotting it in the Approval Requests list on their home page or in the bell notifications, which is easy to miss. An email alert at initial submission uses an email template and sends the moment the request opens, so the approver gets a direct nudge with a link into the record. You can send to more than the approver. Many teams also email the submitter a confirmation, so they know the request is officially in flight, and copy a shared mailbox for an audit trail. The email template can merge in record fields, the submitter name, and the submission comment, which gives the approver enough context to decide without opening five related records. One caution: the approval assignment email that Salesforce sends to the assigned approver is configured on the approval process and the approval step, separate from your custom email alert. It is easy to end up sending two emails at submission. Decide early whether the standard assignment email or your custom alert is the one the approver should act on, and disable or tune the other.
Outbound messages and flows for integration and logic
Initial Submission Actions are not limited to notifications. An outbound message sends a SOAP message containing record fields to an external endpoint the instant the record is submitted. Teams use this to mirror the approval in a connected system, for example queuing the same request in an ERP that runs its own chain. Outbound messages retry on failure for up to 24 hours, so plan a fallback for anything mission critical, because after that window the platform stops trying. The newer addition to this phase is the ability to launch an autolaunched flow as a submission action. A flow can do work that the older action types cannot, such as creating several related records, calling an Apex action, or making a callout with richer error handling than a raw outbound message. Running a flow here is also a stepping stone toward the Flow-based approval model that Salesforce is investing in. If your submission logic is starting to feel cramped inside field updates and email alerts, a flow is usually the cleaner home for it. Keep in mind that any flow you launch runs synchronously in the submission transaction, so a slow flow can delay the user who clicked Submit.
A worked example: a discount approval
Picture a sales process where any opportunity discount above twenty percent needs manager sign-off. The Approval Process entry criteria check the discount percentage. When a rep clicks Submit for Approval and the record qualifies, the Initial Submission Actions run in one shot. First, the built-in lock freezes the opportunity so the rep cannot quietly lower the discount after submitting. Second, a field update sets Approval Status to Pending, which lights the record up on the sales-ops dashboard of open approvals. Third, an email alert goes to the rep manager with the account name, the amount, the discount, and the rep justification merged into the body, plus a link straight to the approval screen. Fourth, an email alert confirms to the rep that the request is live. If the org also feeds deals into a finance system, a fifth action, an outbound message, posts the deal to that endpoint. From the rep point of view, one click produces a locked record, a clear status, and a notified manager. From the manager point of view, an email arrives with everything needed to approve or reject. That coordinated opening state is exactly what Initial Submission Actions exist to create.
Classic versus Flow approval processes
Salesforce now labels the original tool Classic Approval Processes, which signals that a Flow-based approach is the direction of travel. In the Classic model, Initial Submission Actions are a fixed section in the approval process setup, and you pick from field updates, email alerts, tasks, outbound messages, and flows. In a Flow Orchestration or Flow-built approval, the equivalent work happens in flow elements that run before the first approval stage, which gives you full control flow, loops, and decision logic instead of a flat action list. The record lock concept carries over, with its own record-locking behavior in the Flow approval model. For now, existing Classic Approval Processes keep working and remain fully supported, so there is no urgent reason to rebuild a stable process. The practical guidance is to keep maintaining Classic processes you already run, but consider the Flow model for brand-new approvals or for any process whose submission logic has outgrown simple field updates and alerts. Knowing that Initial Submission Actions live inside the Classic model helps you read Salesforce docs correctly, since the newer Flow pages describe the same lifecycle in different terms.
Set up Initial Submission Actions
Initial Submission Actions are configured inside an existing Classic Approval Process. The record lock is created for you, so this is about adding the optional field updates, alerts, tasks, outbound messages, or flows that should fire when a record is first submitted.
- Open the approval process
In Setup, use Quick Find to open Approval Processes, choose the object, and click into the process you want to edit. Scroll to the Initial Submission Actions related list.
- Add an action
From the Add New picklist in the Initial Submission Actions section, pick the action type. You can add an existing action or create a new one inline, then save it back to the process.
- Stamp a status with a field update
Create a field update that sets your Approval Status field to Pending or Submitted. This makes the in-flight state visible to reports, list views, and other automation.
- Notify the approver with an email alert
Add an email alert that targets the first approver, using a template that merges in the key record details and a link to the approval screen. Optionally add a confirmation to the submitter.
- Set who can edit the locked record
On the approval process, set Record Editability to either Administrators only, or Administrators and the assigned approver, so the right people can still update the record while it waits.
Changes a field value at submission, most often setting an Approval Status field to Pending so the request is visible everywhere.
Sends a templated email when the record is submitted, typically to the first approver and sometimes a confirmation to the submitter.
Creates a follow-up task, for example reminding the submitter to chase the approval if it stalls.
Sends a SOAP message with record fields to an external endpoint, useful for mirroring the approval in a connected system.
Launches an autolaunched flow for richer logic, such as creating related records or calling an Apex action at submission.
Controls who can edit the auto-locked record, either administrators only or administrators plus the assigned approver.
- The record lock is automatic and implicit. If a submitted record will not save, check whether it is sitting in an open approval before hunting for other causes.
- Changing Record Editability only affects records submitted after you save the change, not approvals already in flight.
- The standard approval assignment email is separate from any custom email alert, so it is easy to send the approver two emails at submission.
- A flow launched at submission runs synchronously in the same transaction, so a slow flow delays the user who clicked Submit for Approval.
Prefer this walkthrough as its own page? How to Initial Submission Actions in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Initial Submission Actions.
Hands-on resources to go deeper on Initial Submission Actions.
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. When do Initial Submission Actions execute in a Salesforce Approval Process?
Q2. Which setting, fired at initial submission, makes the record read-only for non-admins until the process completes?
Q3. Which set of action categories are the siblings of Initial Submission Actions in an Approval Process?
Discussion
Loading discussion…