Clients may complain about the load times for stages/processes/tasks. This could be raised in scenarios where clients have highly complex journeys configured, and many stages/processes/tasks have conditionality attached for them. For example, a Maintenance journey schema may be configured to cover several different ‘Areas for Change’.
To dig into this, the the journey instance API response can be used.
First, open each of the stages. Check the ‘started’ and ‘completed’ time for each stage.
If any of the stages were completed in a matter of seconds, they would not be the source of delay. They can be disregarded.
For any stage that did have a large time between its start and finish times, check the start and finish times of each of the processes within the stage. Ensure to not mix up the timestamps between the stage/process/task:
If there is a process that took a long time to complete, repeat the same sequence for the tasks within that process. This will then narrow down the source of the delay.
Once the source (s) of the delays have been identified, the next step will depend on the outcome:
It could be that the delay came from a data/risk calculation/external data task. If so, this should be sufficient as an explanation.
It could be that there were processes/tasks that were evaluated and skipped unnecessarily. This may occur if scoping is applied at the task level where it could have been kept at the process level. If the process is evaluated as being out of scope, the system therefore wouldn’t have to evaluate each task in the process. If this is the case, there would likely be configuration improvements that could be made (this would be a matter for the relevant Project team or client config partner).