In Progress

Dynamic Durations in Workflow

Taylor Dent 2 years ago in Productivity Management updated by bart.theys 3 weeks ago 23

Often, we’re able to optimize and simplify workflow processes by using 1 workflow to accommodate many different channels. This is great because we can reduce the amount of configuration in the system and mitigate the amount of maintenance. However, SLAs in this scenario for duration on a task tend to get generalized and are not specific. It would be great if there were a way to set criteria such as a Type to determine which duration would apply on a given task. This way, we could configure many different SLA’s to apply to 1 optimized workflow based on a Type that could be determined up stream in Job Starter, a Planning Task or manually within the Activity or Project Details page.

Hi Eric,

Before closing this ticket, can you feedback on the use case that Joe and myself gave in above thread? It don't understand how the whole feature of project scale, responds to the need to have dynamic durations. It seems to me that it just introduced a few categories of rigid durations. Moreover, the whole concept of selecting a scale when starting a project will often not fit for occasional users, because the work requestor (eg. product manager, marketer,...) does not always have the knowledge or experience to decide about the magnitude of the workflow behind that.

As summarized by Joe, we would like the ability to utilize Start Type of As Soon as Possible and have the end date (=deadline) of the task be set to an EA value. Please look at the scenario above (in my post): a workflow is just unnecessary paused by Aprimo somewhere in the middle, and can eventually sill result in an overdue. Also, this causes the user to have limited insight in priority of upcoming tasks. The signalization on tasks often only show 'Overdue' or '1 day left', while the task could already appear in inbox a week before.


Hi Rachel - great news on Q3/Q4 for this one.

I can't find another voice for the roles so this may have fallen through the cracks.  The ask would be to have the same flexibility you're adding here for durations but for task Assignment.   In our workflow configuration we have multiple copies of tasks everywhere to have both different durations and different roles.  e.g. if France assign task to Role A ("translation coordinator" for examle) if Germany or US assign task to Role B ("creative team lead").  If nothing else is different about that task configuration except the Role it gets assigned to, would be great to combine for less maintenance and more flexibility.

Thank you!


Hi Diana,

Regarding the roles question.  What I would struggle with is "what" makes the determination on which role to use?  For the project duration it will be a "project scale" attribute that determines which duration to use but in your example, swapping around roles could be based on lots of different variables or use cases right?  Your example looks like it would be region but I am guessing for another customer it would something else right?

But rather than discuss this here since we will be closing this Voice item soon once the feature releases can you create a new Voice idea for this topic and then we can continue the discussion further in that thread.


Hi Rachel - 1) do you happen to have any updates on the ETA for this one?  We're excited about it as well.   2) We'd also love dynamic Role Assignments on a task in workflow config as well.  Dreaming?  :)   Thank you!

Hi Diana,

We're still hoping to target a late Q3/early Q4 release for dynamic date durations.

As far as the dynamic Role Assignments on a task, I'm not sure that I've talked about that before with you. Have you talked to Eric about that one, or maybe there's another Voice request for that one that I can look at? I can tell you that it won't be included in the dynamic duration work discussed here.


Not sure if I am completely touching the same topic. But our client also requests a form of dynamic durations. The recently introduced feature to use "Start no later than" together with an offset linked to a datetime EA is a good addition. However, even when all predecessor tasks are completed, a task will only appear in the inbox on the last day possible.

Assume a simple WF with 2 tasks

First solution:

  • Start => Today (June 10th)
  • Step 1 : duration 1 day, start as soon as possible
  • Step 2: duration 1 day, start as soon as possible
  • End => deadline (June 17th => could be an EA or the activity end date).

When I start this WF, and complete Step 1, the second task will immediately appear in my inbox. It will however show a due date of tomorrow (duration of 1 day). That is not very logical, because the project deadline is only next week and I might have more urgent tasks in my inbox.

Second solution:

  • Start => Today (June 10th)
  • Step 1 : duration 1 day, start as soon as possible
  • Step 2: duration 1 day, start no later than (linked with the deadline EA).
  • End => deadline (June 17th).

When I start this WF, and complete Step 1, the second task is not shown and will only appear on June 16th in my inbox.That is not very logical, because the project deadline is already the day after and I might have time now to complete this task already. 

What I am trying to say, is that we would like is a combination of 'Start as soon as possible' (to trigger when a task appears in the inbox) and "End no later than" to set the task deadline. Does this make sense?

Eric - this sounds like the same use case we discussed (either during QBR or Finsync). We also would like the ability to utilize Start Type of As Soon as Possible and have the end date of the task be set to an EA value. Our processes require tasks to be assigned as soon as the predecessor is closed. Current functionality only allows these task End Dates to be set to a static SLA. We need these tasks to assign when the predecessor is closed and have an End Date that is pulled from an EA value (as configured in WF Templates).

Right now we're targeting Q3 for completion. Once we get a little closer I can be more specific.

Is there an expected GL date for this? 

In Progress

We are completely the feature design right now and this should move into development in early March.  High level design is there will be a new system type created with 5 options.  One option will be the "default" and it will always be active.  The remaining 4 options will be "inactive" by default and admins can start to activate them when they are ready to start to use them.  All of the types will allow each customer to change the names (urgent, small, med, large, XL) or whatever to what will fit your business terminology.

On the Step Details page, the duration for the "default" type will always have to be set.  Other types can be added if desired.

When a new project is created, the user will have the option to pick the Scale for the project from the list of "active" options. When the project is initialized, the workflow service will look at each step and see if a duration has been set that matches the scale and if there is one set it will use that duration.  If there is not a match it will use the "default" setting.


Project scale = Small.  Total time = 11 days

  • Step 1 = 2 days
  • Step 2 = 2 days (using default)
  • Step 3 = 1 day
  • Step 4 = 3 days (using default)
  • Step 5 = 1 day (using default)
  • Step 6 = 2 days

Project scale = Large.  Total time = 29 days

  • Step 1 = 7 days
  • Step 2 = 2 days (using default)
  • Step 3 = 3 days (using default)
  • Step 4 = 10 days
  • Step 5 = 5 days
  • Step 6 = 2 days (using default)

Project scale = Default.  Total time = 16 days

  • Step 1 = 5 days
  • Step 2 = 2 days
  • Step 3 = 3 days
  • Step 4 = 3 days
  • Step 5 = 1 day
  • Step 6 = 2 days

We are also going to look at allowing the scale to be changed while the project is running.  When changed, the workflow service would then go through and adjust the duration / due dates for all tasks still in "projected" status to match the new scale selected.  NOTE:  We are still evaluating this portion so we cannot commit right now that adjusting this on live projects will be supported in the MVP release but that is the goal.

All the work has not been sized yet so the release timing cannot be set but the expectation is sometime in Q3.

At Franklin, we don't need dynamic duration on a workflow because we have dynamic duration on a task setup that is based on a selection that has been made by the Job Owner in a previous task.  When it gets to the point in the Project, there are 3 tasks where output ports are looking

for (criteria on Status Actions) duration/turn around time that has been selected.


This is definitely on our roadmap.  I believe Taylor got the idea from seeing my roadmap slides.  But it is not planned for development until late Q3 or Q4 of this year right now.  I will cover this in my roadmap at SYNC for those attending and would happy to discuss it further with anyone who will be there.

Any updates on this?  Would be a big win

Hi Eric,

Any updates on timing or expected functionality for the request?

Thanks Eric - definitely interested in hearing more at SYNC. Have there been discussions around other WF Template items having dynamic functionality enabled? We have the same need for dynamic capabilities when it comes to Attachment Types.  

This sounds similar to what we are wanting to accomplish here at Mutual of Omaha. We have or Project Planner team adjusting a single workflows durations to fit many different types of projects. It would also be great if when copying these projects it would apply the duration edits and not a new template. It is common for our Planners to setup the edited workflow for a campaign that repeats many times during the year.

On behalf of AARP... We too would like to see this ability to have Dynamic Durations. For some workflows, we have as many as 10 SLA Categories (although 5 would probably suffice).  If this was to be applied to a sub workflow, there may be some tasks for which the dynamic duration would not apply.  For example: a specific task always as a 1 day duration regardless of the SLA.   

I agree with this as well.  We have to have separate workflow templates to accomplish this for each task/duration combination which is not easy to maintain and cannot be changed without a new workflow definition version so Release/OCM is involved.

I agree with Scott - allowing the task duration to be applied dynamically based on specific criteria would make using one workflow among many channels/groups much easier. It would also be ideal if a Task SLA could be set to align with a date field that is manually entered. i.e. the End Date of a task would be set to "Task Due Date"  Date EA that was manually entered by a previous task assignee/Project Manager.

I had this on my list to submit, Wells Fargo is very much in favor of this enhancement.  We have had a few conversations with Eric Teitsma about this capability and Eric suggested the ability for Admins to name the SLA categories (such as High, Medium, Low) and then set the duration when configuring the task.  Also the ability to change this value during the workflow as SLAs adjust.  

I would agree this functionality would be useful.    I would like to see the ability to dynamically set duration and roles on tasks with criteria like a port.    Example of roles would be for a review maybe writer and project manager need to review if one condition is true, and just the project manager if a different condition is true.    In regards to duration, I could see multiple levels of complexity and the duration's would match that.    Example would be High, Medium, Low and each would have a separate duration associated with it.   

Hi Scott,

The dynamic roles assignment is another great topic but can you put that in as a new idea as that would be a separate work stream on the R&D side and should have its own discussion in here on how it could work.  Thanks.