Which setting is allowing hours to be allocated to a day off?

[hilk_]

In the screen shot attached you can see in Workload Balancer that there are a couple tasks that are distributing work on days off. Why and how do I fix things so the task isn't allocating on days off? I confirmed that project settings ask to consider user time off.

[DavePa1]

Hi Lyndsy,

The two ways I've found to indicate time off for a user:

1) Entered by the user in their calendar - accessed from the user's profile page.

2) Entered on the Timesheet (this assumes you have the "General Time" section active for your Timesheets.

Hope that's helpful.

Dave

[hilk_]

@Dave Parker‚ Schedules also plays a role. They offer general rules for work, especially to indicate a user's typical work week. I have a schedule in place for this user (and all the others by country). This user's schedule says they don't work weekends. Most of the projects abide by these rules; there are a couple projects, though, that are distributing work over weekend days. That's what I'm trying to fix.

[DavePa1]

When we went to a flex schedule (9/80), we set up another schedule in Workfront to reflect those hours. You can apply schedules on the project level, so perhaps that would help, as it presets the days and hours work can happen.

Does that sound helpful? I think I understand the problem you want to solve.

[hilk_]

Assigning schedules at the project level poses a whole host of new issues if the participants are scattered across the globe. We just don't have our schedules set up to be helpful that way.

All my other projects are appropriately blocking tasking time on days off...except for a couple.

[Sheri_Whitten]

Hi Lyndsy! Did you get this figured out? We used to have that happen all the time when we used the Project setting "Ignore User Time-off" which is how we started in Workfront 3 years ago. We finally got approval to use "Consider User Time-off" and that fixed 99% of projects being allocated on a user's OoO days. Now I only see it happen when someone copies a project with that old setting, or if someone uses a forced constraint. Are any of those things tripping up the schedule for you?

[hilk_]

Thank you for the thoughts, @Sheri Whitten‚. No solution yet. I checked the project: Yes, I have Consider User Time Off selected. Then I checked the task and it's using As Late As Possible.

[Sheri_Whitten]

Hmm, I wonder if the project also has the Schedule Mode set to use the Completion Date and that the completion date is forcing work to be allocated on the user's time-off so that the project can done on the chosen Planned Completion Date. We had so much trouble with using the Completion Date schedule mode setting, that we only use the Start Date. Maybe check that setting and try changing the date or schedule mode to see if it recalculates the timeline (or force it). I have had one project where I could NOT get the timeline to recalculate, so I moved it to Planning, then back to Active and it finally worked. I hope you get it! I enjoy a mystery, but not with my Workfront scheduling 😊

[hilk_]

Toggling completion mode and status didn't change a thing. I think it's time to submit a ticket.

[tracy_fox]

Lyndsy, I have had this issue for quite some time and even tried to get it resolved with a ticket (inconsistent & random, no fix could be found). My schedules are properly denoting work days versus office holidays, my projects denote Consider User Time Off yet hours continue to randomly get assigned on calendar days off.

One note that where this is expected to happen is those tasks that have multiple resources assigned. Where Joe, Jane & Sam are all assigned to a task and Jane has a day off, WF assumes Joe & Sam will pick up the slack.

Fingers crossed you get a better answer than I did!

[hilk_ · Accepted solution]

It took a lot of trial and error, but we did end up finding a solution: Adjust the planned hours, even if it means you have to adjust it back to the originally defined planned hours. Indeed, this still sounds like something hinky is going on, but at least there appears to be a workaround, albeit a not obvious one.