Handle teammate availability when generating schedule


#1

Hello,

It would be great to have a way for teammates to mark themselves as “inavailable” in the future and let the system avoid picking unavailable persons (and fallback to admins if nobody is available).

That would make scheduling so much easier, because currently we basically have to do that manually on a calendar once per month, then schedule overrides based on the availability of people.

Thanks


Why not provide an api to import a rotationless schedule?
#2

Hi Corentin,

This is something we’ve discussed before, but it is introducing a lot of additional questions, which would be complicated to answer inside the product. It is still in the backlog though, but I’m almost sure we won’t be able to deliver something complex in the near term.

Do you think an easier way to add ad-hoc schedules via the UI or the API would make this easier for you? Currently, it is indeed done via Overrides, but I can see why that can be uncomfortable. Or is the request mostly about the calculating an equal amount of scheduled on-call time based on the availability information?


#3

Hello,

We’re currently already using the overrides, and some teams have a script to generate them based on a calendar, that isn’t perfect but is somewhat works. We use per-period (month or quarter most of the time) to try to ensure fairness.

Maybe a good way for you to experiment with that would be to provide an external script (part of one of your SDK) that does something similar, see how user use it most of the time, and later implement that in the app itself ?

I think our current script works this way:

  • Users define availability in a shared calandar
  • The script tries to pick an available user with the least hours oncall during the period, and that was also, if possible, not oncall the last shift
  • If none are available, we do the same on admins, not taking availability into account

I’ll try to see if we can put in on github


#4

I’ve seen such scripts before and indeed is a way to do it, but it’s the first time I’m seeing that it is actually trying to distribute the on-call times evenly. If you could share that with the community on github, that would be really awesome!

I’ll be looping in the product team on our side to see what can be done about it - having it as an external function, for now, sounds like something we could definitely do.

Thanks again for the feedback and for the ideas Corentin, detailed and valuable as always!