Visual Workflow – When to Run the Flow for Updated Records

Entries in the Setup | Time-Based Workflow using every time a record is updated and meets the condition requirements

Appear

• When the record matches the Flow's entry criteria. And only the first time unless DML causes the record to no longer qualify for entry (see Disappear) at which point the next time DML occurs to satisfy the entry criteria, a new TBW is created from the scheduled path.

Disappear

• When the record no longer matches the Flow's entry criteria or
• When the time trigger transpires and the scheduled path executes

Adjust

• When the reference date(time) of the scheduled path changes value on any DML operation.

Once the record has already generated the TBW events, changing any other field value on that record will not cause the flow to even execute, let alone any new TBWs to appear.

To solve your issue, some options:

• Use created and every time it is edited (which can lead to many, unintended TBWs)
• Have a separate Flow to handle the additional field, perhaps using subflows to handle shared logic

The confusion I think is coming from the fact that the flow is being configured to re-trigger when the Event.DueDate is changed.

What actually happens with Flow Time Triggers is that the Time Based Workflow re-evaluates the Event.DueDate against the Flow criteria when the Event is changed. Automatically. Under the hood.

There are the steps that the Time Trigger follows

1. Create a record that meets the criteria of the Time Trigger
2. Time Based Workflow record is created with a ScheduledDate set by the flow (e.g. 1 day before ActivityDate)
3. When the Trigger Date is changed (in this case Event.ActivityDate) the time based workflow automatically re-evaluates the Event against the same Flow
4. Because the Flow is creating a Slack post 1 day before the DueDate, if the due date has changed, the TimeBased Workflow.ScheduledDate is updated accordingly.

I'm pretty confident that combining a Flow Time Trigger with and Async Trigger isn't possible.

The reason being

• The Time Trigger should be triggered when the record is created or changed
• The Time Trigger must reference a date/datetime field
• The Async trigger requires the inclusion of the IsChanged operator or must be triggered when the record is updated to meet the criteria
• The IsChanged Operator is not compatible with the datetime field in the criteria.

Trying to get around this may well be possible, but I would urge against it because it will just create mess (i makes my head hurt trying to devise a workaround). Save yourself a headache and just just have two flows, one for your Time Trigger and another for the Async flow. :)