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 appointments, delete them, save layouts.
  • Data-driven security answers what can this user see? Which tasks land in their open task list and which resources 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 group, 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 values are the individual entries. Region with EMEA, LATAM and APAC. Skill with the skills 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, then assign values to your users, resources and tasks. 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.

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