7.3 Approval Processes, Email Alerts, and Notification Patterns

Approval processes as controlled gates

An approval process is appropriate when a record must pass through a formal review before work continues. Common examples include discounts, contract exceptions, expense requests, knowledge article publication, high-risk account changes, or service credits. The value is not only that someone receives a message. The value is the submission event, approval steps, assigned approvers, record locking options, approval history, and final approval or rejection actions.

Approval process setup is found from Setup > Process Automation > Approval Processes. The admin defines the object, entry criteria, submitter settings, initial submission actions, approval steps, rejection behavior, recall behavior, and final actions. Each step can use criteria and assigned approvers. Approvers may be specific users, related users such as a manager, queues where supported by the process design, or delegated approver arrangements.

Entry criteria are the front door. If criteria are too broad, users submit records that do not need review. If criteria are too narrow, risky records bypass the gate. A discount process might require approval only when discount percent exceeds a threshold, amount is above a level, or a regulated product is included. The admin should confirm whether criteria use current field values, record type, owner role, region, or a custom approval status field.

Record locking must be understood. Locking can prevent users from editing a submitted record while approval is pending, which protects review integrity. However, it can also block legitimate operational edits, integrations, or data corrections. If a locked record needs updates, the admin must know who can unlock, whether final actions update fields, and how rejected records return to users for correction. Locking is a control, not a decoration.

Notifications and alerts design aid

Email alerts are configured as reusable actions and can be invoked by approval processes, Flow, or other automation patterns depending on the org. Email templates should use fields that recipients are allowed to see and understand. For internal messages, include a record link, owner, status, and the action required. For external messages, validate branding, opt-out expectations, compliance language, and whether the message should be sent from Salesforce at all.

Custom notifications are often better than email when the recipient works in Salesforce all day or uses the mobile app. They can point users back to a record and avoid inbox clutter. They are not a replacement for a formal approval process when approval history and locking are required. They also need an audience strategy. Sending every notification to every manager will train users to ignore the system.

Notification design checklist:

• Identify the action the recipient must take after receiving the message.
• Confirm the recipient has record access and the right permission to complete the action.
• Decide whether the message is immediate, scheduled, one-time, or repeatable.
• Avoid including sensitive field values when a link to the secured record is safer.
• Test email deliverability, template merge fields, mobile display, and queue behavior.
• Monitor volume after release and remove duplicate alerts.

Approval scenarios and traps

Consider a high-discount opportunity approval. Sales reps submit the opportunity when discount percent is above 20 percent. The first step goes to the rep's manager. If the discount is above 35 percent or the amount is above 250,000, a second step goes to finance. Initial submission locks the record and sets Approval Status to Pending. Final approval sets Approval Status to Approved and notifies the deal desk. Final rejection sets Approval Status to Rejected and creates a task for the rep to revise terms.

This design has several test cases. A rep without a manager should not strand the request. A manager on vacation should have a delegated approver or operational coverage. A finance approver must be able to view the opportunity fields needed for review. A rejected opportunity must become editable enough for correction. A discount changed after approval may need resubmission. A data load should not accidentally submit hundreds of deals without business intent.

Approval and Flow can cooperate, but the boundary should be clean. Use approval processes for the formal gate and Flow for supporting actions that do not belong naturally in approval steps, such as creating a related implementation checklist after final approval. Avoid building a parallel approval engine in Flow unless the process requirement truly cannot be met by approval features. A custom flow-based approval is harder to audit and maintain unless the org has a deliberate reason.

Agentforce may help users prepare a submission summary or find policy guidance, but it should not silently approve records that require human accountability. If an AI-assisted experience suggests an approval path, the admin should verify permissions, grounding data, audit needs, and human review. The safer pattern is AI-assisted preparation plus deterministic approval routing.

Study traps include confusing notification with approval, assuming an email alert changes record access, and forgetting that record locking can block other automation. Another trap is placing all approvers in one step when the business requires sequential review. Read scenario wording carefully. If the requirement says approve, reject, lock, route to approver, or keep approval history, think approval process. If it only says inform a user or team, a notification pattern may be enough.