We have run into a few snags with how Shifts and Schedules currently works that have prevented us from using the feature, and instead build a custom widget to support what we need.
Would like to see the following improvements within the Shifts and Schedules feature:
- Currently shifts are only available on an instance level. This is part of the reason it is a non-starter feature for us - within one plant we have different shift schedules per department.
- Only defaults for a repeating week. Should be able to plan for things like specific events, holidays, planned shutdowns, last minute timing changes, and overtime.
- Permissions - I want to empower a line supervisor to be able to set shift times themselves, but not have access to things they shouldn’t in the Tulip instance. Give us an easy out-of-the-box solution for surfacing the interface within an app and restricting to certain employees.
I think Aubrey brings up some great examples of things which are very hard to do or impossible within Tulip now. However, I generally disagree that these types of requests should be baked into the Shifts and Schedules component of the platform. I think it is contradictory to the general nature of Tulip as a platform and not a solution. Instead it would make more sense to continue to build functionality that makes it easier for Tulip developers to build custom logic such as above. Or provide a set of library tables with some example architecture for controlling this.
Currently shifts are only available on an instance level. This is part of the reason it is a non-starter feature for us - within one plant we have different shift schedules per department.
This is something which will likely have to be solved with a configurable table anyway. Every business will have different hierarchies which they want to use. So instead of creating a more complex feature, it just needs to be easier to use a Tulip table as a lookup when calculating shifts.
Only defaults for a repeating week. Should be able to plan for things like specific events, holidays, planned shutdowns, last minute timing changes, and overtime.
Similar sentiment to above, this needs to be something which can be controlled via a Tulip table. There is just too much variability.
Permissions - I want to empower a line supervisor to be able to set shift times themselves, but not have access to things they shouldn’t in the Tulip instance. Give us an easy out-of-the-box solution for surfacing the interface within an app and restricting to certain employees.
This could be built very easily if the shifts and schedules were managed in Tulip tables. And the access control system/logic would be just like other supervisor apps.
Hi Audrey, thanks for sharing this. Agreed that this is a gap in the offering currently. We have found that this one small feature brings a lot of varied types of feature requests, which brings us to… the response from @danielpomeranz.
Yes, this is a prime example where the primitives of Tulip may need to be improved (Tables, Automations, Stations perhaps) in order to support a more extensible solution. As Dan noted, it is very difficult for Tulip to build a feature like this and support the wide variety of use cases, and that calls for a more open-ended solution that potentially includes an SDK or similar.
But, for the time being, we do not have any concrete plans to work on this feature until we come up with a better long term plan. A couple follow ups on your points, Audrey:
- Shifts at an instance level: Are you familiar with the Workspaces feature? Once Workspaces are turned on, shifts and schedules go to the workspace level.
- Agreed on this point. The future solution would need to handle this.
- Permissions- Have you started using Custom User Roles yet? There is a toggle in Custom User Roles to allow any role to get access to Shifts and Schedules.
Agreed - totally understand the angle of making the primitives better to support a more extensible solution here. Some responses below -
- Yes, am familiar with workspaces. Doesn’t solve our need for the following - 1) our IT has forced us to have unique instances per site / not workspaces 2) we need granularity down, not up - we need to be able to have more granularity within one site/instance for schedule and shift variation than is there today (like being able to say certain days are holidays, or certain departments within one site have different shift start and end times or breaks)
- Agreed!
- We have been implementing custom user roles - but this isn’t the solve for what we need. I don’t want 80 supervisors on the floor to have access to the back end or shift configurations for the whole site - I want an easy widget I can put in an application so that a supervisor can update the shift of their department from the application on the floor directly without logging in to the back end. We built a widget for this, but it is a common enough use case that it would be great to see one provided for it.
Looks like I need to do a long form post of how we handle shifts. For now see if this is enough of a hint…
We have two ways to handle shifts that work for both machines and applications.
Evenly Repeating shifts
In some areas we have repeating shifts (Shift 1, 2, 3 every 8 hours). For those I calculate the current shift in Node Red and publish to MQTT which can be piped into a machine activity table column.
I could probably refactor this to work for applications as well (create a REST endpoint in Node Red) but it was simpler for applications to create a table containing shifts and start times. Once you have that you can get the current (or N number of previous) shifts using a connector function or table aggregation. The advantage of the connector function is you get tuples of the shift and start time. To do the same in an aggregation you would have to setup 2 since you can only return one field in each.
Here’s the connector function version.
Non-evenly Repeating shifts
This is done exclusively using tables. We have an A/B/C/D rotation 12 hour shift. I populated a Tulip table with a year or two of data. Like above this can be retrieved using a connector function or table aggregation.
Understood. Makes sense. Yes, I think we will probably want to handle this with a more generic feature in the future, but we do not have a native way to handle this well currently.