I'm currently struggling really bad with this lacking feature as well, but as far as I am told, the system is designed currently to not dynamically update any durations, due dates, etc. as the delivery plan progresses. Those values are calculated up front when the delivery moment is started, and once started, does not update. So in your scenario:
-- The due dates of each tasks are based on the duration you have specified in the task plan.
-- If the tasks are conditional based on some field that changes during delivery phase, there is no way for the system to know which task will run and will not depending on your settings up front, so it just adds up all the durations to come up with the overall duration.
-- If some task is completed early, for example, your second task tasks 1 day instead of 3, the remaining tasks due dates are not recalculated, and just remains as is. So if your last task is the only one that runs, and first 3 are skipped, your entire duration will still be 20 days, and worst part is that your last tasks due date is actually shown as 20 days out. So even though you expect your last task's OLA/SLA to be 10 days, system actually has it as 20 days now.
-- This most importantly, throws out escalations out the window, wihch is based off of the due dates of tasks, since they will never be reliable if we are basing our task OLA/SLA on how long each individual task should take (actual start date to actual complete date). It will also make the whole due date etc. shown in delivery progress page inaccurate.
I have a support case open for this, but not sure what the current plan is to address this, as I am sure this is not a simple update to make happen...
The system has to improve the intelligence to calculate and show the duration of a request when it is moved to the workflow. After the approval, the system will know which tasks will be available and which will be skipped.
For those tasks, they can calculate and show the duration.
For the tasks which may / may not be executed based on the conditions, they can provide an approximate duration such as a range of business days (just a suggestion).
For my case, only one task will be executed based on the value of a field which will be set during the approval.
This document explains the logic to develop Tidal Enterprise
Orchestrator workflow to automate the process of creating vCenter
Resource Pool* vSphere Power CLI must be installed either on the TEO
server or vCenter* vMA can also be used to achieve the same...
IntorductionCisco Process Orcehstrator (CPO) ships with the webservices
adapter that can be used to make Web Service API call to REST or SOAP
based applications. Before a sample workflow to make SOAP API calls
using CPO, lets understand some of the fundam...