Hello everybody!
At my organization, we've been deeply embedded in classic/legacy Workflow based process engine design for a long time...and we are migrating as much as we can to modern Flows using Flow Designer and Catalog Builder.
I developed a very basic flow, which will do the very basic (minimum) for what our business wants, from the request/fulfill form style, where an SP form gathers info and then creates a single task (no approval) and assigns that single task to the fulfiller group (defined on the item itself) for fulfillment.
I want the SCTASK created in the flow to always have the same information (variables) that the RITM has, so that my fulfillers do not need to navigate to the RITM, to get that detail. We have use cases where we do not want them to access that info in the RITM and we want the variables to be accessible directly on the task.
In some cases, my SCTASK has the variables and sometimes it simply does not...and I am at a loss, with regards to why that is. I can't even replicate this on my PDI, it seems like the OOB behaviour is for it to not behave as I want.
...it seems like the features of Flow Designer will require me to author a specific flow for each and every Catalog Item, which I want to apply this VERY BASIC flow to...which seems "wrong", to me.
What makes matters worse, is that this works in my instance (as is) for some catalog items, perfectly...the flow in the attached screenshot is used for both of the RITMs, resulting in the respective SCTASKs, which both have different outcomes, seemingly without any logical explanation...one has the same variables that you see on the RITM, the other does not (sometimes, its just a few, sometimes it is none).
...I'm dumbfounded and I will just create individual specific flows for each and every catalog item, to achieve these results if I have to...but that seems wrong. I kinda refuse to believe that I cannot simply design a flow which looks to the Catalog Item for the fulfillment group and then just creates a single task assigned to that group, with whatever variables on the item, present on the task...especially since it is behaving the way I want it to in practice (evidenced with my screenshots here)...
...I'm sure there is something I am missing which is present on the items, where this works...but not on the ones, where it does not.
Any help/advice is greatly appreciated! TIA! -- I always mark helpful and accept solution, when appropriate -- so, please give it your best shot!
Again, I understand how I can create a specific copy of this exact flow for each item and then identify that specific item as the "Template catalog item" on the flow and manually specify which fields need to be "selected" (from "available") - which would be all of them, every time...but I would prefer to not have to do that. I would rather not have to specify that explicitly on a individual flow for each flow, when a genericized version of that flow exists (conceptually).
I am aware that I can also change behaviour in my organization - by having the fulfillers not expect that detail on the task, directing to the ritm...but neither of those ideas really solve my problem as I've been directed to ensure the task has all of the relevant info, with as little overhead as possible, with a simple modern flow, to easily scale-out in our organization...and we aren't going to scale-out very easily if I have to create a specific flow and specify every variable for every item...seems like a drastic step backwards to me.
It's possible that "as little overhead as possible" is quite literally manually defining and writing an individual flow for all items -- but that really really doesn't seem like the "champion behaviour" on the "platform of platforms"...that's pretty "amateur hour" IMO...
>>>> Here is a good example of this working for me just fine (these screenshots are from our production instance):
Catalog Item:
Flow 1:
Flow 2:
RITM:
SCTASK:
....this is exactly what I want...I want the flow to just create a task and assign it to the fulfillment group on the item with all of the same variables on the task, as on the item.
I do have UI Policy on this item, to show and hide particular fields in a responsive sense...but the problem I am having persists on items which have no UI Policy...or a lot more UI Policy than this one, so that doesn't seem to be a point of friction -- and I have tried to add an "on load" (not reverse if false) UI Policy, with no condition, that sets the "visibility" value of any (all) variables to "true"...and checked that to apply on all Catalog Item, Req Item, Cat Task views...so it should in theory just work, as I expect -- but yet, that's not the experience I am having.
I suppose I am more frustrated with (alarmed by?) the fact that I can replicate this in my PDI (not working, as I guess is expected?)...but then why does this work fine here in the example in this post? This should not work, if I can't get it to work in my PDI...what am I doing in this item, to get this to work as I like...that is not happening in so many other random items in my instance - or a newly created item...or one in my PDI...
