Flow Designer patters to make "inflight" flows accept changes?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-23-2024 02:29 AM
What are you all using to have your flows be accepting of changes?
Inflight flows have an instance of the flow, so if you are in prod, flow version 1 is running, then you push a change that modifies flow 1 the instance of flow 1 running will not take that change as its "inflight". And then you have to turn them off by script and restart them, which can create task duplication if tasks are created in the flows.
ITSM has flows per STATE instate, and until PAD there as not place to visually group and see the entire flow from start to finish unless you created ONE flow for the entire lifecycle.
One flow for the entire lifecycle though means the flow is "inflight" from start to finish of a ticket, and has the main root problem.
One flow driver with wait for conditions that trigger subflows (a pattern used to better organize application files and and make it more self documenting visually, if PAD is not available) has the same problem.
It seems that only path forward really to solve this is use pad, have flows per STATE or a similar thing so that flows are in fact...not in flight so that when changes are pushed to prod there are less things in flight. So how are other architects designing flows so that you don't have "inflight flow" issues in prod?
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-23-2024 07:50 AM
Hi Corbett,
It is a great question and from my experience as an architect it is best to handle this via business change (i.e. internal process communication) then building something to update inflight flows.
1. Firstly it goes against the ServiceNow flow architecture so any changes to implement this is essentially going against platform architecture
2. Based on the flow it could have different levels of complexity and impact.
As a result utilising business change to do the following;
1. Communications around the date of the flow to be released to production and therefore if there are any active requests that need to be cancelled and created a new after the flow has been processed should be communicated (usually the support team would handle that)
2. Or the support team will deal with the in flight requests and any new tickets will follow the new process.
Hope that helps though it might not be the answer you were looking for.
Kind Regards,
Wind
