Cancel Changes Using Flow designer

[El Cuchi]

Hi all,

I want to develop a solution where i cancel all changes (including their change tasks), if they are in NEW state and have not been updated for the last 30 or 60 days (not too relevant).

I created a scheduled job that works and i thought that maybe doing it in flow designer would be better.

i created a flow where the trigger is everyday @ 10am

first is a look up records in the change table where state is new (-5) and updated is older than 30 days. Second activity is a "for each" of the records found in the look up. Third activity is another 'for each" where i search for change tasks related to changes from first 'for each' and if they are not closed then i cancel them

Fourth, outside the second 'for each' i do have an activity to cancel the change record (after closing all change tasks.

Issue

the result of the lookup is empty (0). After several testings i realised that the date filter (older than 30 days) is causing the issue. if i remove it and leave just state is NEW. Then, it works.

I also try replacing the lookup with a custom script but i face the same issue.

Question

is it possible that flow cannot cope with this filter? would you know how to do it in flow?

regards,

Max

[Matthew_13 · Accepted solution]

Hi Buddy,

The issue isnt that Flow can’t handle the filter, it’s that the “older than 30 days” condition doesn’t always evaluate reliably in a Lookup Records step, especially when it’s applied to a date/time field like Updated. Because of that, the lookup ends up returning zero records even though you know matching records exist.

The easiest and most reliable way to fix this is to calculate the date first, and then compare against it.

Try this approach I use and that usually works well:

• First, get the current date/time in the flow.

• Then subtract 30 (or 60) days from it.

• In your Lookup Records step, filter where:

  • State = New

  • Updated is before the calculated date

Using “is before” with a concrete date/time value is much more predictable than using “older than X days”.

Another reliable option is to use an encoded query in the lookup, for example:

state=New^sys_updated_on<javascript&colon;gs.daysAgo(30)

This behaves the same way as list filters and avoids the Flow condition-builder quirks.

Basically:

• Flow Designer can absolutely do this

• The “older than” operator is what’s tripping you up

• Calculating a cutoff date (or using an encoded query) is the clean workaround

Your overall design — scheduled flow, looping through changes, cancelling tasks first, then cancelling the change — is solid.

You just need to tweak how the date filter is handled.

@El Cuchi - Please mark Accepted Solution and Thumbs Up if you found Helpful

[El Cuchi]

Hi Matt,

Thank you so much for taking the time to look into this.

As per your suggestion i tried using "

state=New^sys_updated_on<javascript&colon;gs.daysAgo(30)"
  

and did not work.

Also, created a flow variable called cutoff where the code is 

var gdt = new GlideDateTime();

gdt.addDaysUTC(-30); // Subtract 90 days

return gdt.getValue();

Then, i compared sys_updated_on before the flow variable.

Same result.

When using second option the variable is the first step and the log shows the correct result. 

Cutoff Date     2026-01-05 23:36:07

in the first look up i can read in the log

Conditions

active=true state=-5 sys_updated_on<2026-01-05 23:38:39

Everything looks ok but it is not working....

regards,

Max

[Matthew_13]

The first thing I’d check is whether there are truly any records that meet “State = New and not updated in 30 days.”
Remember that sys_updated_on changes any time anything touches the record — flows, business rules, integrations, assignment rules, even small background updates. So a record can sit in “New” for a long time but still have a recent sys_updated_on, which means it won’t match your filter.

Try running the exact same filter directly in the list view. If that also returns zero records, then Flow is actually working fine — it just means nothing currently meets that condition. In that case, you may want to use sys_created_on instead, or a custom date field that only changes when real progress happens.

If the list view does return records but Flow still shows zero, then it’s likely a context issue — for example the flow running as a user or in a domain that doesn’t have visibility to those records. Setting the flow to run as System usually resolves that.

@El Cuchi - Please mark Accepted Solution and Thumbs Up if you found Helpful

[Matthew_13]

Ok lets figure out