Containers
A container is a meta entity that groups records together and allows the planner to schedule those records as if it was one entity. It's a flexible tool to enforce business rules and they can be used in a variety of ways, such as creating trips, enforce work breakdown structures, manufacturing sequences, and more.
Containers are to tasks and appointments what roles are to user actions: they group tasks into a single logical unit, allowing the application to treat the container as a proxy for all the records that are linked to it. Instead of manipulating them one by one, containers can be leveraged to achieve the same thing in bulk.
Containers by themselves in Dime.Scheduler don't assume any behavior, rather than visualizing its members and enabling drag and drop operations on container level. Naturally, the back office system can step in and alter the behavior of the container when needed.
This concept is put into action in the open tasks grid and affects the map and planning board.
How it works
The data model of a container could not be any simpler. It simply represents an entity, which other entities such as tasks and appointments use to define a relationship between them.
Container: Assemble bikes for Bill (invoice for company - order A01234) and his son (privately billed - order A01235)
├─ Task: Assemble bike for Bill
├─ Task: Assemble bike for Bill's son
By default, tasks in the planning board are planned one by one. Even though there are links to other tasks (through service lines, job planning lines, assembly lines, etc.), the planner still needs to plan every task individually. Containers introduce another way of planning in which tasks are planned as a group. A container effectively becomes a proxy task that happens to hold a series of tasks. Appointments and tasks still exist individually, and can be planned as such, but now there's a super entity that links to other related appointments.
For example, if a customer has two open orders, it would make sense to execute both of them at the same time. In the back office system, it is possible that these two orders don't have a direct link. A container could provide a solution as any appointment and any task can be linked.
When something changes in the planning, the planner could manually reschedule all affected appointments, or simply reschedule the container, which in turn will update the records inside the container.
There aren't any constraints attached to a container, by default. The container needs a name and a color and contains a collection of tasks and appointments. What those tasks and appointments are, doesn't matter. Containers may spread across resources and departments and appointments from any order can be planned through the same container, everything is possible with containers.
Task and appointment containers
Currently two entities can use the container meta entity: tasks and appointments. Eventually, every task will be converted into an appointment (i.e. a planned task), but before a task is planned, planners can already define a relationship between tasks through task containers. When dragged on the planning board, the appointments will already be rendered inside a container.
When the order is created and ready to plan, the container will hold two tasks:
Container: Assemble bikes for Bill (invoice for company - order A01234) and his son (privately billed - order A01235)
├─ Task: Assemble bike for Bill
├─ Task: Assemble bike for Bill's son
When scheduled, two additional members will be added to the container:
Container: Assemble bikes for Bill (invoice for company - order A01234) and his son (privately billed - order A01235)
├─ Task: Assemble bike for Bill
├─ Task: Assemble bike for Bill's son
├─ Appointment: Assemble bike for Bill - 2022/05/01 10:00
├─ Appointment: Assemble bike for Bill's son - 2022/05/01 12:00
Tasks and appointments can be added to a container at the planner's discretion at any time.
Map
When tasks (across jobs) are selected in the open tasks grid, the map component will add pins to the map that correspond to the locations of the selected jobs. When a task is connected to other tasks through one of its containers, the linked tasks will automatically be embedded on the map. For example, selecting one task automatically loads the connected tasks as well:
Users that require the map to plan trips for their resources will benefit from this feature in a major way. It is easy to see how much easier it is to determine the most efficient route when all related tasks are put on the map immediately. Automated mechanisms like this will reduce human errors and will reduce the time of planning as well.
Planning board
Drag and drop task containers
Assuming a task container is defined and tasks are assigned to it, planning a task – by dragging it on the planning board - will automatically plan all the other tasks that belong to the same container. When dragging a task, the tooltip will immediately tell you which tasks are about to be planned. In the example below, you'll find that dragging a container-backed task will drag other related tasks (as defined by the containers) to the planning board:
Dropping such a task or set of tasks will immediately render a container on the planning board.
Creating containers on the planning board
The above workflow is an easy way to get your tasks linked from the outset. But it needn't be that way as Dime.Scheduler provides all the tools to manage containers. By selecting appointments on the planning board and using the shortcut key SHIFT + G or through the context menu, you can create containers and add or remove members:
Give the container a name and a color and you'll be left with the following view:
Multi-resource containers
When a container spreads multiple resources, a vertical handlebar is displayed. This bar can be locked or unlocked, either by clicking on the lock icon or double clicking on the vertical handlebar. When it is unlocked, the handlebar can be moved freely without dragging the container members along with it. When the handlebar is locked, the container members will be dragged along with the handlebar. When a container has multiple members on the same resource, a rectangle is drawn around the members. The bar is draggable and will drag the appointments in the container for this resources along with it.
Validation rules are executed in the same fashion as individual appointments. As soon as one appointment fails validation, the entire container drag and drop action is rendered invalid and won't allow the container to drop.
Single-resource containers
The horizontal bar that's drawn around the container members of a resource can also be used to reallocate the resource through simple drag and drop, just like you're used to with individual appointments in the planning board:
Validation rules are executed in the same fashion as individual appointments. As soon as one appointment fails validation, the entire container drag and drop action is rendered invalid and won't allow the container to drop.
Appointment's context menu
Through the context menu of the container and the individual appointments, you can add or remove members to a container.
Either option will prompt a dropdown list so the user can select which container should add or remove a member (except when an appointment is assigned only to one container). That's right, an appointment or task can have multiple containers. This opens up a world of possibilities and allows for complex relationships between tasks:
Container's context menu
Both the horizontal and vertical bars (and the lines that link to the vertical bar) expose a context menu on right click and containers a number of actions to manage the container:
The planner can:
- Show the entire container in the planning board
- Edit the name and color
- In case of the existence of a vertical handle bar, lock or unlock the bar
- Add an appointment or container
- Remove the container
- Remove the container and its members
A container can only be removed in the planning board when the container doesn't hold task members. When the container does have tasks, it will only remove the appointment members.
Toggling containers visibility
The button in the planning board's toolbar allows you to toggle the visibility of containers in the planning board.
Application setup
The feature flag 'Enable appointment containers' in the application setup should be enabled in order to visualize and use appointment containers. No data is lost in the process of toggling this feature: it merely activates or deactivates the feature in the planning board.
This setting is cached in the browser. Please notify the users to hit CTRL + F5 in their browser in order to apply (most of) the new application settings in the planning view.