Creating shifts automatically with automations

Shifts can be added by hand from the Shifts tab on a job, but there are two ways to have them created automatically instead, so nobody has to build them one at a time.

Using the Create a Shift automation action

Inside any automation, add an action called Create a Shift. It asks for a user, which is required, and a role, which is optional.

This suits a specific situation well, when you’re assigning a particular person to a shift based on some logic earlier in the automation, a condition that always routes a certain kind of booking to a certain person, for example. What it isn’t good for is dynamic, general purpose staffing, since you’re hardcoding exactly who gets assigned rather than letting the system work that out from who’s actually available.

A typical setup looks like this. A trigger such as a booking being amended, an If Else step checking some condition, and on the true branch, once whatever needs to happen has happened, a Create a Shift step at the end assigning a specific user. The user field has to be filled in for this to work properly, an empty user field leaves the step incomplete and flags a warning until it’s set.

Using the Units and Users service type

This is the better option for staffing that should happen dynamically rather than being tied to one named person, and it’s set up on the service itself rather than inside an automation.

Open the service, go to its Availability tab, and set the Availability Type to Units and Users.

Add and enable the units the service actually needs, the physical bookable items involved. Then choose a team, which brings up a list of that team’s members, and enable whichever of them are actually eligible to work this particular service. Not everyone on the team has to be included, so this is where you narrow it down to the right people rather than the whole team by default. Finally, set how many team members are required for the service to be considered available at all.

Once this is configured, booking the service checks both sides, a qualified unit and enough eligible, available team members, and assigns from whoever’s genuinely free at the time rather than a name you’ve fixed in advance. When a user gets assigned this way, their shift is created automatically as part of it.

Which one to actually use

Reach for Create a Shift inside an automation when you already know exactly who should be assigned and the decision is really a piece of logic, not a staffing problem.

Reach for the Units and Users service type for everything else, which in practice is most shift creation. It’s the option that scales properly, since it draws from your actual roster and their actual availability rather than needing a specific person named inside every automation you build.