Crews
Most planning is one resource at a time: this technician, this van, this afternoon. But plenty of work does not divide that way. A two-person installation team always travels together. A shift needs three welders and it does not matter which three. A departmentDepartmentA grouping of resources used to sort and group rows on the planning board and in the grids. As a group behavior in the crews view, a department cannot be booked; it exists for structure and reporting.'s total capacityCapacityThe amount of working time a resource has available in a given period, used to spot over- and under-planning. matters for reporting even though nobody ever books "the department".
A crewCrewA resource that stands for a group of other resources. Dropping work on a crew fans the booking out to every member, which suits people who always work together. is how you describe those situations. It is a resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. that stands for a group of other resources, so a planner can drop work on the group and let Dime.Scheduler work out what that means for the people inside it.
You manage crews from the Crews view on the Resources page. The view is a tree: a group's members sit under it, nested as deep as the groups go, and the Group behavior column says what kind of group each one is.
The crews view
The three kinds of group
The single most important choice you make about a group is its group behavior, because it decides what happens when a planner drops an appointmentAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board. on it. There are three options and they are genuinely different, not variations on a theme.
| Group behavior | What a planner sees | What happens on assignment |
|---|---|---|
| Crew / team | A bookable lane | The booking fans out to every member |
| Pool | A bookable lane | One slot is held against the pool, to be named later |
| Department | Not bookable | Nothing. It exists for structure and reporting |
Crew / team
Use this when the members always work together. Assigning the crew creates an assignmentAssignmentThe link between an appointment and a resource. An appointment can carry several assignments when more than one resource works on it. for the crew and one for each of its members, so everybody's calendar reflects the job and nobody is double-booked elsewhere.
This is the "two-person installation team" case. The planner books once and three calendars fill in.
Pool
Use this when you know how many people you need but not yet who. Assigning a poolPoolA group resource for work where you know how many people you need but not yet who. Assigning a pool holds one slot against the pool itself, to be resolved to a named resource later. holds one slot against the pool itself and does not touch the members. Later, somebody resolves that held slot to a named resource.
This is the "three welders, any three" case. It lets you commit to the shape of the plan early and to the names late, which is usually how shift planning actually works.
Department
Use this when the grouping is organizational rather than operational. A department cannot be assigned work at all: planners cannot drop on it, and the API refuses it too. What it gives you is a level in the tree to roll capacity and reporting up to.
The refusal is deliberate. Booking "Field Services" would look like scheduling but would commit nobody, and a plan that looks full while nobody is actually booked is worse than an empty one.
Membership
A group's members are the resources inside it, managed from the Members panel of the crew editor. Pick them from the Available resources list, which you can narrow with resource filters when the roster is large.
Membership can be time-bound. Member from and Member until record the window a membership applies to, which is how you model somebody joining a crew in March and leaving in September without losing the history of what they were part of in between. Leave both empty for an open-ended membership.
Nesting
A group can sit inside another group. The Part of field names its parent, and a resource has at most one parent: if you move a resource that already belongs elsewhere, Dime.Scheduler tells you so and saving keeps only the group you selected.
Three rules constrain the tree, and the editor stops you rather than letting you save something unplannable:
- A resource cannot be a member of itself.
- Groups cannot contain each other, directly or through a chain of other groups. The editor marks a candidate that would close a loop with Would make the groups contain each other.
- A crew may only contain individual resources or other crews. Putting a pool or a department inside a crew is blocked with A crew can only contain individual resources or other crews.
The last rule exists because fanning a booking out has to terminate in real people. A pool deliberately does not resolve to people yet, and a department deliberately never does, so neither can sit in the path of a fan-out.
Capacity
The second choice to make about a group is where its capacity comes from. The Capacity field has two settings.
From its members is the default and is usually what you want. The group's capacity is the sum of the capacity of the individual resources inside it, counted per day, and each member is counted once even if the tree reaches them by more than one path. Add someone to a crew and the crew's capacity grows on its own.
Managed on the group treats the group as having capacity in its own right, taken from its own capacity entries. Use it when the group's availability is not simply the sum of its parts: a room that holds four people regardless of how many are on the roster, or a shift with a fixed headcount. Capacity per day sets the figure to fall back on for days that have no capacity entry of their own.
A group's own assignments are never counted twice against its members. See resource capacity for how capacity is generated and edited for individual resources.
How crews behave once work is planned
Two behaviors are worth knowing before you roll crews out, because they are the ones that surprise people.
Fan-out happens when the assignment is created, not continuously. If somebody joins a crew next week, the jobs the crew was already assigned to are not rewritten to include them. This keeps a published plan stable: changing a team's roster does not silently reshuffle work that people have already been told about. To bring a new member into existing work, assign them to it.
Removing the crew from a task takes its derived members with it. The members were there because the crew was, so the members go when the crew goes.
Planners work with crews on the crew planning board, where each crew is a lane with its members nested underneath, so a booking on the crew and what it means for each person are visible together.
Keeping crews in step with the back office
Crews can be maintained here by hand, or synchronized from the system that already knows your team structure. The membership edges are exposed through the API as resource members, so an ERP or HR system can push them in the same way it pushes resources. See resource member for the contract.
Note the split: membership is synchronizable, but whether a resource is a group at all, and which of the three behaviors it has, is configured here in Dime.Scheduler. Those are planning decisions rather than master data.