Process Builder - Scheduled Processes in previous versions

Question

NOTE - Related to this post

Scenario: Case Status change to 'Pending' triggers Reminder Emails every 2, 3 and 5 days ultimately setting the Status to 'Solved'

Issue: Let's say the above scenario is executed in Process Version 1 - (V1), i.e., the 'Pending' Case process is currently scheduled and will keep running unless the Status is changed to, say, Open. Let's say we deploy a V2 of the Process and deactivate V1 (where the flow interview was in-flight). Now, changing the Case Status to 'Open' in V2 doesnt overwrite/change the behaviour of the schedule already running in V1. As a result, the 'Pending' flow (from V1) completes to 'Solved' even though it logically shouldnt (considering the Case got Re-Opened in V2). I believe this is something related to versioning of processes and that the schedules running in V1 lose their association once that version is deactivated - Is this true? I read this post for reference and this article by Salesforce, but there doesnt seem to be a prescribed best practice or solution for this scenario.

What's the best practice for long running schedules when deploying a new version of the above process? Do we need to do a data update activity everytime before(for the previous version)/after deployment(for current version) of these Process versions?

There's are references (below) to this issue but going through Paused Flow Interviews and deleting for 100's of such Cases is not practical, especially since we cant really figure out which nodes actually triggered the flow (there are other nodes which trigger different schedules).

Any suggestions would be helpful. Thanks! :)

References - REF 1 , REF 2 , REF 3

Answer 1

According to SF Trailhead documentation here and here, the drawback of scheduled flows running to completion is not mentioned when a Process is cloned/upgraded to a new version.

There are 2 ways to solve this problem. Let's assume you have a Master Process for an object -

1. Splitting Schedules from Process Builder: This primarily involves moving all your time-based nodes from the Master Process into a separate 'Master Schedule Process' for the object. Now all the immediate actions will be in the Master Process and the time-based ones will be in the Master Schedule Process. This is useful if your organization has matured time-based SLA's that rarely require to be upgraded. As such whenever you need to change immediate workflows based on your releases, you need to upgrade and deploy the Master Process, thereby not affecting the already running version of the 'Master Schedule Process'.
2. Use Time-based Workflows: Remove the time-based process node and convert them to time-based workflows instead. Workflows dont have versioning issues, but they are legacy and SF is moving/will move away from workflows eventually. Additionally, they can become harder to manage as you dont have an order / 'view' of all the time-based workflows for the object.

For point 1, when an upgrade is required for Master Schedule Process to introduce/update a time-based node, you could run a report (for example Case Lifecycle Report) or check scheduled flow inteviews and mass update the 'to-be impacted' records prior to and post deployment. I would consider Point 2 (Workflows) to be a safer option for tracking & troubleshooting but they can only process simple logics.

I'd happy to hear any more approaches to solve this problem.