Hi, we have an IVR Flow that is currently working fine, we have added Flow Outcomes and Milestones to report results. Keeping it simple
Customer ID&Vs
(Flow 1) Option 1 - Make a Payment - ... Initialise Flow Outcome
Triggered Flow - (CM) Common Module collects Payment Amount
Passes to (SF) Secure Flow - Collects Payment Card Details, and Authorises Transaction
Success or Failure set against Flow Outcome based on result of authorisation
We see statistics that indicate Success and Failure, within the SF and with timings against the Flow Outcome that are on a par with what we would expect this process to take.
However ... We are also seeing 0 success 100% fail against the Flow 1 Payment Flow Outcome Initialisation.
Is there a way to stop this occurring as its making our stats look like 65% or payments are declining, when its nearer 30% ??? I almost get why its happening as its a different flow - but for the timing statistic to be right on the SP Success/Failure, it must be using the one initialised in Flow 1, so why is that Flow Outcome left hanging to fail by default ??
Only option I can think of is to Initialise when we get to the Secure Flow, but that is not measuring the entire process.
Could you just call the Common Module from the Secure flow? You probably thought of that, but is there any reason why you couldn't do this? Then, this would allow you to set the Flow Outcome Success at the beginning of the Secure Flow, because it does represent the start of the process.
Its a possibility Peter, but the Common Module collects the payment amount, and we perform various logic checks on Payment amount that will result on a decision on whether we collect card details (hence the Secure Flow) or that the Customer needs to pay in a different way, in which case a Secure Flow is not necessary.
Flow outcomes / milestones are scoped to the flow instance in which they are running. When it comes to a common module, everything should continue to work in a similar manner in that the common module is embedded within the parent flow from that perspective. When it comes to transferring to another flow, if the flow tries to set a flow outcome value there, that flow outcome is not somehow tied to the flow outcome instance initialized in the calling flow. It would be a new flow outcome tied to that flow instance. The idea of sharing flow outcomes and even multiple of the same outcome in the same flow instance were discussed during chartering but ended up not being part of the final delivery of the project.
I would recommend you take a look at our Idea's portal here and submit an idea if this is a feature you think would be useful.
Thanks,
John Carnell
Director, Developer Engagement
Thanks John, appreciate the feedback and investigation, I will submit as suggested as whilst I understand the answer and viewpoint and even why the decision was made, I do believe that we are losing a useful metric by not allowing the Flow Outcome to cross the 'border' into a follow on Flow.