Data-driven security
Dime.Scheduler secures access in two layers. The first layer, role-based access control (RBAC), uses rolesUser roleA named bundle of user actions assigned to users and user groups. Permissions flow through roles, never directly to a user. and user actionsUser actionA single protected capability, such as 'edit appointment', that a role can grant. The building block of role-based access control. to define what a user can do. This page covers the second layer: data-driven securityData-driven securityRestricting which records a user can see based on the data itself - for example a region or business unit - rather than on their role., which controls what data a user can see and plan. A simple matching algorithm decides which tasks and resources appear for each user, and this page explains how to set it up.
Filter groups & filter values​
Filter groupsFilter groupA configurable set of fields used to filter resources and tasks on the planning board. and filter valuesFilter valueA single value inside a filter group, used as a qualification on a resource or a requirement on a task. are how you enforce data-driven security across planners, tasks and resources. A filter value is a requirement or restriction you set on one of those entities. A filter group is simply a logical grouping of related filter values.
Here are some examples of filter groups and their values:
- Region
- EMEA
- LATAM
- APAC
- Skill
- Servers and networks
- Basic PC knowledge
- Programming
- Department
- Administration
- Production
- Sales
When you plan tasks across geographical regions or multiple companies, the customer may want a dedicated planner for each region. The same goes for assigning planners to specific types of work such as room bookings, ship crews, product assembly, or servicing. These are exactly the scenarios filter values are built for.
You can assign filter values to three entities:
- Users
- Tasks
- Resources
A filter value on a task acts as an eligibility requirement for users and resources. A user must meet a task's requirements to plan it (or even see it). For resources, the requirements determine who is qualified to perform the task.
Dime.Scheduler runs these calculations automatically, so a user only sees the tasks and resources they are allowed to plan. From there, the user plans their open tasks freely. Finding the right resource for each task is a separate concern: as explained in the resource filters section, Dime.Scheduler does not enforce this automatically but gives you the tools to steer the planner in the right direction.
An example makes the mechanism concrete. Using the filter groups and values above, assume the following entity filter values:
| Type | Name | Regions | Skills | Departments |
|---|---|---|---|---|
| User | John Doe | EMEA | Basic PC knowledge, Programming | / |
| User | Jane Doe | LATAM | Basic PC knowledge | Sales |
| Resource | Hank Dover | LATAM | Basic PC knowledge, Servers and networks | / |
| Resource | Bill Jensen | EMEA, LATAM | Basic PC knowledge | / |
| Task | Install software | EMEA | Basic PC knowledge | Administration |
Now it is time to plan the "Install software" task. Two levels of data-driven security come into play:
- A user must be authorized to plan the task and must be able to plan at least one resource. This level is automatic and outside the user's control.
- After that, the planner decides which resource to assign to the task.
The user, and optionally the resource, must meet the requirements the task sets. This check runs at filter group level. In this example, the task has requirements in three filter groups:
- The task will be performed in the "EMEA" region
- The task requires a minimum knowledge (skill) of "Basic PC knowledge"
- The task will be done in the "administration" department
Looking at the users, both John Doe and Jane Doe have the required skill (Basic PC knowledge). But Jane Doe can only schedule tasks for the "sales" department and the "LATAM" region, so she is ruled out. John Doe passes every check, even though he has no assigned department filter value. As explained in the management by exception principle section, a filter group is ignored when a user or resource has no assigned values for that group. As a result, Jane Doe never sees the task in her open task list, while John Doe does. The same calculation runs for resources: a user only sees resources they are allowed to see, based on the filter values of both the user and the resources. John Doe will not see "Hank Dover" because their regions differ (EMEA vs LATAM), whereas Jane Doe sees both resources.
The planner decides how and when to plan the task, and to whom to assign it. Unlike the link between user filter values and the task filter, the user can choose whether or not to honor the requirements on the task. A resource may not be qualified for the task, so it is up to the planner to build a realistic plan.
Categories and time markers​
Data-driven security is not limited to filter values and filter groups. Categories and time markers indicate the status of an appointmentAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board., which you can also use to enforce security rules. For example, you can filter out appointments with the category "Completed" so users cannot modify the planning of work that is already done.
Management by exception principle​
The data-driven security algorithm for filter values, categories and time markers follows the management by exception principle. When no values are specified for a given filter group, the user automatically has access to all values in that group. This keeps things easy to maintain: when new values are added to a group, the user automatically gets access to them, with no extra permission management. The same principle applies to categories and time markers.