This should be a Before-Save Flow, specifically configured with "Optimize the Flow for Fast Field Updates," because the entire requirement is scoped to updating a field on the SAME record that triggered the Flow, which is exactly the scenario Before-Save is designed to handle most efficiently. A Before-Save Flow folds this field change directly into the save that is already in progress, requiring only ONE database write total, whereas an equivalent After-Save Flow would need to perform a separate, second Update Records action after the initial save already completed, requiring two total database writes to achieve the identical outcome. Beyond the pure efficiency argument, using Before-Save here also avoids any recursion risk entirely, since the change is folded into the original save event rather than triggering a new, separate save that could potentially re-invoke the same Flow.

A Before-Save Flow, specifically one optimized for Fast Field Updates, is structurally restricted to only modifying fields on the SAME record that triggered it — this is not a configuration option that can be adjusted, it is a fundamental capability boundary of that execution mode, which does not support creating, updating, or deleting any OTHER record, nor does it support other After-Save-only actions like sending emails or invoking Apex. This restriction exists because Before-Save Flows run at a point in the Order of Execution before the triggering record has even been committed to the database, and touching other records at that specific moment is outside the platform's supported before-save automation model. Any requirement needing to update a genuinely different record, such as a related Account, structurally requires an After-Save Flow instead, since only After-Save execution has the capability to perform DML against records beyond the one that triggered the Flow.

Flow recursion occurs when a Record-Triggered Flow's own action causes the same record to be saved again, which can potentially re-trigger that same Flow, creating a repeating cycle that in a worst case becomes an effectively infinite loop only stopped by Salesforce's own recursion or governor limit protections. Before-Save Flows updating the same record are inherently safer from this risk because their field changes are folded directly into the ORIGINAL save event that is already in progress — no new, separate save transaction is created, so there is no additional save event that could re-invoke the Flow. An After-Save Flow performing the equivalent same-record update, by contrast, must use a separate Update Records action AFTER the initial save has already completed, and this action itself constitutes a genuinely new save event, which could potentially re-trigger the same After-Save Flow if its entry conditions still match, creating the exact recursive cycle that Before-Save's folded-in approach avoids entirely by design.

This happens because of where each mechanism sits in the Order of Execution: Before-Save Record-Triggered Flows run at an earlier point in the sequence, specifically before Custom Validation Rules evaluate. By the time the Validation Rule checks whether Priority is blank, the Before-Save Flow has already run and defaulted the field to "Medium," meaning the record's actual state at the point the Validation Rule evaluates no longer has a blank Priority field at all — the Validation Rule is correctly checking the CURRENT record state, which reflects the already-defaulted value, not the user's original blank submission. This is not a malfunction of either mechanism; both are working exactly as designed, but their combined effect is that the Validation Rule can never actually catch a blank Priority in this specific configuration, since the Before-Save Flow's defaulting logic always resolves the blank condition before the Validation Rule has any opportunity to evaluate it.

$Record gives direct access to the triggering record's CURRENT field values at that point in the Flow's execution, while $Record__Prior gives access to the record's field values as they existed BEFORE this specific save occurred, allowing the Flow to compare old versus new values without needing a separate Get Records element, directly mirroring the role PRIORVALUE() plays within Validation Rule formulas. $Record__Prior is not meaningful on a Create-triggered Flow, because a brand-new record being created for the very first time has no genuine prior state to reference — the record did not exist before this save, so $Record__Prior in this context would generally reflect default or empty values rather than any real previous state. Logic that depends on comparing old versus new values using $Record__Prior should therefore be scoped specifically to Update-triggered Flows, where a genuine prior state actually exists to compare against.

The sequence begins with the original record being loaded and compared against submitted values, followed by system-level validation such as required field and data type checks. Before-Save Record-Triggered Flows run next, along with any before-triggers if Apex is present, meaning they execute early enough to modify the record's field values before anything downstream evaluates them. Duplicate Rules evaluate next, followed by Custom Validation Rules, which critically run AFTER Before-Save Flows have already had a chance to modify the record — meaning Validation Rules always see the post-Before-Save-Flow state of the record, not the raw, originally-submitted values, and if any Validation Rule fails at this point, the entire save is rolled back and nothing further in the sequence happens. Assuming validation passes, the record is saved to the database, after which after-triggers run, followed by After-Save Record-Triggered Flows, meaning After-Save Flows only ever see a record that has ALREADY successfully passed all Validation Rules and been committed — they cannot prevent a save the way Validation Rules can, since by the time they run, the save has already succeeded. The sequence continues with legacy Assignment/Auto-Response/Workflow Rules, Escalation Rules, Entitlement processes, Roll-Up Summary recalculation on parent records, and Sharing Rule evaluation, before the final commit completes.