<h2>Flow Action "Updated Multiple Records"</h2><br/><div style="overflow-x:auto"><article><div ><h3 >Issue </h3><section><div><span style="font-size: 12pt;"><strong>Current Behavior:</strong></span></div> <div>1. "Update multiple records" action will not update the "updated" field.</div> <div>2. Records that are updated by the "Update multiple records" action will not trigger another flow.</div> <div> </div> <div><span style="font-size: 12pt;"><strong>Reason:</strong></span></div> <div>This is expected behavior and it matches the equivalent scripting API - GlideRecord.updateMultiple().</div> <div> </div> <div>UpdateMultiple could potentially update millions of records at once and shouldn't trigger flows. It actually will skip both BR and engines (Workflow, Flow, Field Normalization, Approval,etc) during the db operation.</div> <div> </div> <div>But, there are some conditions where the underlying persistence code falls back to doing iterative single update operations instead of a single update operation on multiple records. In that case, the single record update operations do run BRs and engines. The table being audited is one of the conditions that force this fallback behavior.</div> <div> </div> <div>Actually, the Update Multiple Records action uses GlideRecord.updateMultiple() so it should match that method in all cases.</div> <div> </div> <div><span style="font-size: 12pt;"><strong>Resolution:</strong></span></div> <div>For behavior 1, You can explicitly set the update time by adding that to the fields that will be updated. The value to use can be picked from an existing DateTime pill or you can get the current datetime with a scripted input:</div> <div> </div> <div>return new GlideDateTime();</div> <div> </div> <div>For behavior 2, you can use "Look up records" and "For..Each" action instead.</div></section></div></article></div>