the evaluation of "wait for condition" to true, does not always match a data pill's valueDescriptionif you have a "wait for condition" activity and it evaluates to true and flow moves forward, and you have a data pill configured for the same table/field from the WFC, intermittently that data pill will contain the previous value, not the value that caused the WFC to move forwardSteps to Reproduce - apply the Update Set to any out-of-the-box instance - go to fix script, and execute/sys_script_fix.do?sys_id=7d77ca033b861a103ed2da6eb5e45a37- out of 500 runs about 3 flow contexts will contain the unexpected behavior - to find out which ones look for the following system log entries:https://<instance_name>.service-now.com/syslog_list.do?sysparm_query=sys_created_onONToday%40javascript%3Ags.daysAgoStart(0)%40javascript%3Ags.daysAgoEnd(0)%5EmessageSTARTSWITH!!!!!%20alert&sysparm_view=WorkaroundNote: if issue is a non-Wait For Condition (WFC), Flow major engine version 2 situation, where the parent flow data record pill is not reflecting changes from a subflow see PRB1829297.This situation with Wait For Condition is how flow designer has always worked in flow major engine version 1 and 2. Using a Wait For Condition will pause the flow, sometime async later, a database record change will meet the WFC condition and the flow resumes. A previous to WFC step data record Pill should not be used in subsequent to the WFC steps. Either add a Look Up the record or use the WFC pill that was used in the WFC condition. This the nature of Wait For Condition as the flow is going into a paused state and async background operations resume the flow later.Related Problem: PRB1832892