A Get Records element is used to retrieve the existing data, configured with the Contact as a filter criterion and Status not equal to a closed value, storing the result in a Variable for use later in the Flow. If no matching open Case exists for that Contact, the Get Records element does not produce an error or fault by default — it simply results in an empty Variable, with no data stored. This is an important behavior to design around: if later Flow logic references that Variable without first checking whether it is actually populated, such as through a Decision element checking whether a record was found, the Flow can behave unpredictably or encounter issues when it later tries to use data from what is actually an empty result, which is why pairing Get Records with an explicit "was anything found" check is considered a standard defensive pattern.

Placing a data operation element like Get Records or Update Records inside a Loop means that element executes once for EVERY single iteration of the loop, so processing a Collection of, for example, 500 records would trigger 500 separate database operations rather than one efficient, bulk operation — this pattern can quickly approach or exceed Salesforce's governor limits, which exist specifically to protect the shared, multi-tenant infrastructure discussed back in Module 0 from any single process consuming excessive resources. The recommended alternative, often called "bulkifying" the logic, is to move data operations OUTSIDE the Loop wherever possible, instead using the Loop purely to build up or evaluate a Collection in memory through Assignment elements, and then performing a single Create, Update, or Delete Records operation against the ENTIRE Collection at once after the Loop completes, dramatically reducing the number of actual database operations regardless of how many records are being processed.

The Equals operator completely replaces a Variable's current value with the new value being assigned, discarding whatever was previously stored, while the Add operator appends the new value onto an existing Collection Variable, or adds to a running numeric total, preserving what was already there. If Equals is mistakenly used inside a Loop where Add was actually needed, such as trying to build up a running list across multiple iterations, the Variable would be overwritten fresh on every single pass, meaning only the LAST value processed would remain by the time the Loop finishes, silently losing every earlier iteration's contribution with no error message indicating anything went wrong. Conversely, if Add is mistakenly used where a single, direct value replacement (Equals) was actually intended, values could incorrectly accumulate or append when the requirement was simply to set one clean, final value, again producing silently incorrect results rather than an obvious failure.

Flow evaluates a Decision element's Outcomes in the exact order they appear, from top to bottom, and takes the FIRST Outcome whose condition evaluates to true, immediately ignoring any other Outcomes further down the list even if their conditions would also technically match the same record's data. This means Outcome ORDER is a meaningful design decision, not an arbitrary visual arrangement — if a broader, more general condition is placed above a narrower, more specific one that should take precedence, the general condition will incorrectly "win" every time, since it is evaluated and matched first, and the more specific Outcome below it will never actually be reached for records that satisfy both conditions. The correct practice, mirroring the same principle from nested IF() statements in Module 11, is to always order Outcomes from most specific to most general, ensuring narrower, more precise conditions get the chance to match before broader fallback conditions.

A Collection Variable is specifically designed to hold MULTIPLE values or records simultaneously, as opposed to a standard Variable which holds exactly one value at a time, and a Loop element is built specifically to iterate through a Collection, processing each individual item within it one at a time across successive passes through the loop's internal logic. A Loop cannot meaningfully operate on a single-record Variable because there is fundamentally nothing to iterate over — a single Variable holds one discrete value with no internal sequence of items to step through, so attempting to loop over it would either be a configuration error or would simply execute the loop body exactly once with no genuine repetition occurring, defeating the entire purpose of using a Loop element in the first place. This is precisely why any Get Records element intended to feed a subsequent Loop must be explicitly configured to store "all matching records" as a Collection, rather than "only the first record," which is the setting that would produce an incompatible single-record Variable instead.

The Flow needs four core Elements arranged in a specific sequence to satisfy both the functional requirement and the governor limit consideration from Concept 5's gotcha. First, a single Get Records element queries all open Opportunities where the Close Date is before today, storing every match as ONE Collection Variable rather than querying individually later, satisfying the bulkification principle by performing this database read only once regardless of how many Opportunities match. Second, a Decision element checks whether that Collection is actually empty, routing to a clean end state if no stale Opportunities were found, avoiding unnecessary further processing. Third, on the "records found" path, a Loop element iterates through the Collection, and inside the loop, an Assignment element (not a live Update Records call) marks or collects each Opportunity's needed change into an in-memory structure. Fourth, and critically, AFTER the Loop completes, a single Update Records element performs one bulk update against the entire modified Collection at once, rather than placing an Update Records element inside the Loop itself, which would trigger one database write per Opportunity and risk exactly the governor limit problem this design is meant to avoid.