Dynamically change the default flow action in Customer Service app
Is there a way to dynamically change the likelihood of flow action?
Or any way to achieve below use case OOTB?
Based on a given condition, we want to show a different flow action when we launch a flow.
Pegasystems Inc.
FR
Can this be helpful: https://collaborate.pega.com/discussion/dynamic-likelihood
Pegasystems Inc.
AU
Does it have to be the same assignment shape? Would the likelihood outcome change in between creating the assignment and seeking to perform it?
I wonder if you can achieve the outcome by having two identical assignment shapes, one with A=60/B=40; the other with A=40/B=60, and implement the condition (that you were hoping to apply dynamically) in a decision shape that precedes the two assignments, taking a path to the assignment with the appropriate likelihood combination.
Encapsulating the assignment and flow actions into its own flow that is circumstanced on something that maintains the outcome of the decision is another approach that would avoid an explosion of logic branches from that decision shape.
If you need to apply the condition at the last possible moment, I've not seen it done. If sorting the pyFlowActionsList from the Dynamic Likelihood article that Marc referenced influences the default flow action then perhaps works, but I fear the consequences of altering the order of elements in this list.
Accepted Solution
Updated: 5 Feb 2021 8:51 EST
Pegasystems Inc.
US
@BraamCLSA thanks for the information.
We solved the problem by overriding CS extension point for perform default - CSPerformDefaultsExt - and set newAssignPage.pyDefaultActionIndex. Looks like this index is mapped to the likelihood of each flow action from the assignment shape and determines which flow action to display.
Earlier when we extended Work-.PerformDefaults to do the same, it broke the blue chevron of left nav (below Add Task+ menu in Customer Service) when we launched a new intent. Work-.PerformDefaults might be the solution for a non-CS application only.
Pegasystems Inc.
AU
The various PerformDefaults extensions are going to run whenever any assignment in your application is being performed. Does this need to dynamically change the likelihood have to engage in most/all of your assignments, or just one (or a small number)?
I would be wary of putting something in a very widely executed extension point that needs to apply to a small number of scenarios. This suggests you need an expression in your all-purpose activity that interrogates exactly where you are in the case lifecycle, which can be brittle.
Class-specializing the extension point to the case type(s) where this should engage would be a first path to 'scoping' this to a limited set of possible scenarios. Be wary of the possibility that moving the stage or step that the flow action occurs in may invalidate the condition you use to match it.
Updated: 8 Feb 2021 8:07 EST
Pegasystems Inc.
US
@BraamCLSA That is a good point to bring out. We're also aware of this and saved CSPerformDefaultsExt in the specific work class with two WHEN conditions to narrow the scope. However, this logic may break if the likelihood of flow actions or stage/process/step changes in future; thus someone needs to maintain it (which can be difficult to do consistently in long term). As a mitigation, we added an annotation to the flow rule and documented the rules so that someone is aware of it.
For now, this is the only working solution we found. Hopefully there would be a more robust and easier OOTB solution to set a default flow action, which seems a common use case. Perhaps as a future product enhancement, a flow action rule could have a WHEN field that sets it as a default flow action or some other way.
Pegasystems Inc.
AU
All it would need is for the Likelihood field in the Flow Action connector on the Flow rule to accept some sort of dynamic value so that likelihood could be evaluated based on a runtime calculation instead of design-time hard-coding.
Ideally, some Property on the Case has a Declare Expression that calculates the respective likelihoods, and the Flow Action connector references the Property bound to that Declare Expression. Have you tried configuring Likelihood to a property or GRS reference? (I haven't)
Pegasystems Inc.
US
Changing the likelihood of flow actions dynamically in activity/DT could be another option, probably more robust in terms of maintenance. I haven't found an easy OOTB way for that. Will need to research more on this.