Skip to main content
Cookbook · Setup & access

Lock down with data-driven security

Admin ~15 min

Roles control which features a user can use. Data-driven security controls which records they can see - useful when planners should only manage their region or business unit.

Before you start​

Dime.Scheduler secures access in two independent layers, and mixing them up is the usual source of confusion:

  • Role-based access control answers what can this user do? Create appointmentsAppointmentA task scheduled to a resource for a specific period - the scheduled instance you see on the planning board., delete them, save layoutsLayoutA saved arrangement of the planning board - visible resources, columns, and settings - that can be reused..
  • 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. answers what can this user see? Which tasksTaskA unit of work that belongs to a job. It appears in the open task list until it is scheduled to a resource. land in their open taskOpen taskA task that has not been scheduled yet. It waits in the open task list to be placed on the planning board. list and which resourcesResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board. appear on their board.

This recipe is about the second. If your problem is "this planner should not be allowed to delete appointments", you want roles instead.

One principle governs everything below, and it is the opposite of what most people assume. Dime.Scheduler follows management by exception: when a user has no values assigned for a filter groupFilter groupA configurable set of fields used to filter resources and tasks on the planning board., that group is ignored for them and they see everything in it. Blank means unrestricted, not restricted. This keeps the setup maintainable, because adding a new value to a group does not require revisiting every user, but it does mean a half-configured user is an unrestricted user.

1. Understand the model​

Filter groups are logical groupings; filter valuesFilter valueA single value inside a filter group, used as a qualification on a resource or a requirement on a task. are the individual entries. Region with EMEA, LATAM and APAC. Skill with the skillsSkillA qualification a resource holds and a task can require, typically modeled as a filter group. Skills drive resource filtering, the project team view and the solver’s choice of who can do what. you care about. Department, and so on.

You assign filter values to three kinds of entity, and each assignment means something different:

  • On a task, a filter value is a requirement: what it takes to be allowed to plan this work.
  • On a user, it is what that planner is authorized for.
  • On a resource, it is what that resource is qualified for.

Start by reading authentication and authorization for how the two layers sit together.

2. Design the groups before you create them​

This is the step people skip, and it is the one that costs the most to undo. Every filter group you add multiplies the assignments you have to maintain across users, resources, and tasks.

Model only the dimensions that genuinely gate access. Region and department usually do. Skill often does not: it describes who is suitable rather than who is permitted, and suitability is better handled with resource filters, which guide the planner without hard-blocking them.

3. Configure the rules​

Create the groups and values on the filter groups page if the back office does not send them, then assign values to your users, resources and tasks. For users that is the Filter Values tab beneath the grid on the users page; when a whole team shares the same scope, set it once on a user group and add the planners to the group. Remember the exception principle while you do it: leaving a group blank on a user grants access to all of it.

The matching runs at filter group level, and it runs automatically. A planner sees a task only if they satisfy the task's requirements in every group where they have values assigned. The same calculation then runs over resources, so a planner only sees resources they are cleared for.

Worth knowing: the check is enforced for the planner, but not for the assignment. Dime.Scheduler decides which tasks and resources a planner can see, and then trusts them to build a sensible plan from what remains. A planner can assign a task to a resource that does not meet its requirements. If you need to steer that choice, resource filters are the tool.

4. Consider categories and time markers​

Data-driven security is not limited to filter values. Categories and time markers carry appointment status, and you can secure on those too. The classic use is filtering out appointments marked Completed so nobody re-plans finished work.

They are assigned on the same panel as the filter values, on the Categories and Time Markers tabs, and the same management-by-exception rule applies here.

Verify​

Test with a real account, not by reading the configuration. Sign in as a restricted planner and confirm two separate things: that their open task list excludes work outside their scope, and that their board excludes resources outside it. Those are two different calculations and one can be right while the other is wrong.

Then test the inverse. Sign in as a planner who should see everything and confirm they still do, because an over-tight rule is easy to miss when you only ever test the restricted case.

Last updated on by Hendrik Bulens