Entry Criteria is evaluated once, at the moment a record is submitted for approval, and determines whether the record is allowed to enter the Approval Process at all — a record failing Entry Criteria cannot be submitted into this process in the first place. Step Criteria, by contrast, is configured on an INDIVIDUAL step within a process the record has already successfully entered, and determines whether that SPECIFIC step applies to this particular record as it moves through the chain, allowing different records to take different paths through the same overall multi-step process. For example, a record might satisfy the overall Entry Criteria of "Discount over 20%" and be submitted successfully, but if its discount is only 25%, it might not meet a later step's own narrower criteria of "Discount over 35%," causing it to skip that specific step entirely while still remaining fully inside the same Approval Process, ultimately reaching Final Approval through a shorter path than a record with a higher discount would take.

Hardcoding a specific named user as the approver ties the entire Approval Process to that one individual's continued presence and role within the organization — if that person leaves the company, changes departments, or is simply on extended leave, the Approval Process has no built-in way to adapt, and every submission requiring that approver's action will stall indefinitely until an Admin manually intervenes to reconfigure it. "Record Owner's Manager" instead dynamically resolves the approver at the moment of submission by looking up whatever value is currently set in the Manager field on the record owner's own User record, meaning the correct approver is automatically determined based on the CURRENT reporting structure at submission time, directly connecting back to the Role Hierarchy and Manager field concepts from Module 4. This makes the Approval Process automatically resilient to normal organizational changes like promotions, department transfers, and reporting line updates, without requiring any manual reconfiguration of the Approval Process itself whenever personnel changes occur.

Salesforce automatically locks a record upon submission to guarantee that whatever an approver reviews and ultimately approves is genuinely the exact same data that was originally submitted, preserving the integrity of the approval decision itself. Without this locking, the record owner or any other user with edit access could modify the record's fields WHILE it is still sitting in the approval queue awaiting review, meaning an approver could unknowingly approve a materially different record than the one that was actually submitted — for example, a Sales Rep submitting a 25% discount for approval, then quietly editing it to 40% before the Manager actually reviews it, resulting in the Manager unknowingly approving a discount level they never actually saw or agreed to. Record locking closes this integrity gap by making the record non-editable by standard users for the entire duration it is pending approval, only unlocking automatically once the approval process fully resolves to either Approved or Rejected, or being manually unlocked by a user with sufficient override permissions like Modify All Data.

This is designed as a single Approval Process with two sequential Steps, where the overall process Entry Criteria captures any discount requiring approval at all, such as greater than a base threshold, allowing any qualifying record to enter the process. Step 1, requiring Manager approval, would have no additional Step Criteria beyond simply being required for every record that enters the process at all, since every discount needing approval requires at least a Manager's sign-off. Step 2, requiring Finance approval, would have its OWN narrower Step Criteria set to the higher threshold specifically distinguishing large discounts from small ones — meaning after Step 1's Manager approval, records with a smaller discount that do not meet Step 2's criteria skip that step entirely and proceed straight to Final Approval, while records with a larger discount that DO meet Step 2's criteria continue into Finance Review before reaching Final Approval. This single process with conditional step criteria elegantly expresses the entire tiered business policy without needing two disconnected processes that would each require independently maintained entry logic and risk records being submitted into the wrong one.

The solution is a Record-Triggered Flow on Opportunity, configured to fire on create or update with an Entry Condition matching the same discount threshold the Approval Process cares about, and configured as an After-Save Flow since triggering an approval submission is an Invocable Action only available in that context, not Before-Save. Inside this Flow, an Action element specifically calling the "Submit for Approval" Invocable Action is configured to run against the triggering record itself, meaning the moment a Sales Rep saves an Opportunity with a qualifying discount, the Flow automatically and immediately submits it into the existing Approval Process without requiring any manual click from the Sales Rep at all. This combines Flow's strength in automatically detecting a triggering condition and firing an action instantly and reliably, with the Approval Process's existing, already-built structured multi-step review chain, record locking, and outcome actions — the Flow handles WHEN the submission happens, while the Approval Process itself continues to handle the actual human review exactly as it did before, requiring no changes to the Approval Process itself.

Flow is the better choice when the actual requirement is complex conditional logic, data manipulation, or automated decision-making that does not genuinely require a human being to review and explicitly sign off — for example, automatically approving or flagging a record based purely on calculated criteria with no human judgment actually needed, or a process requiring extensive branching logic, loops over related records, or integration with external systems, none of which Approval Processes are designed to handle natively. Approval Processes are purpose-built specifically for scenarios requiring a genuine human decision point with structured routing, automatic record locking to preserve data integrity during review, and native support for multi-step sequential sign-off chains, which would require significant custom effort to replicate faithfully in Flow alone, including manually implementing locking behavior that Approval Processes provide automatically. The deciding question is whether a real human needs to look at the record and make a judgment call before it proceeds — if yes, an Approval Process is likely the right primary tool, potentially triggered automatically by a Flow; if the "approval" is really just automated conditional logic with no genuine human review needed, Flow alone is the more appropriate and simpler tool.