Resource access rules let you control who can see and book a specific resource beyond the broad member and non-member booking settings. Each rule is attached to one resource and either whitelists or blacklists a chosen target. Targets can be an individual member or an entire plan, so you can build a whitelist that keeps a resource private to certain people or plans, or a blacklist that carves specific people out of a resource everyone else can use.
Rules are managed from the Permissions tab when you edit a resource. To learn about resources in general, see Resources overview and Booking a resource.
What a rule is
Every access rule belongs to a single resource and has the following parts:
- Mode: either whitelist (allow) or blacklist (block).
- Target type: either a member or a plan.
- Target: the specific member or plan the rule applies to.
- Reason: an optional note you can record when blacklisting a target.
When the target is a plan, the rule matches any member who currently holds an active assignment for that plan. This means you can grant or revoke access for a whole group of people at once by targeting the plan they are on, rather than adding a rule for each person individually. For more on plans and how members are placed on them, see Plans and memberships and Assignments.
Whitelist versus blacklist
The two modes do opposite jobs:
- Whitelist (allow): As soon as a resource has at least one whitelist entry, the resource becomes private. Only members who match a whitelist entry, either directly or through a plan they are on, can see and book it. Everyone else is shut out, including the general public.
- Blacklist (block): A blacklist entry denies a specific member or plan. The rest of the audience for the resource is unaffected.
You can mix both on the same resource. For example, you can whitelist a plan so only members on that plan can book a room, then add a blacklist entry for one person on that plan who should not have access.
How rules are evaluated
When Deskie decides whether a given member can access a resource, it applies a fixed order of precedence:
- Blacklist wins first. If any blacklist entry matches the member, either by targeting them directly or by targeting a plan they currently hold, access is denied. This is true even if a whitelist entry would otherwise let them in.
- Then the whitelist. If the member is not blacklisted and the resource has any whitelist entries, they are allowed only if at least one whitelist entry matches them. If the resource has whitelist entries and none of them match, access is denied, because the resource is effectively private to its whitelist.
- Otherwise, fall back to the resource settings. If the resource has no whitelist entries and the member is not blacklisted, Deskie defers to the resource's existing member and non-member booking settings. This covers both a resource with no access rules at all and a resource that has only blacklist entries.
Blacklist taking priority over whitelist is deliberate. It lets you exclude a single member from an otherwise whitelist-only resource without having to rebuild the whitelist around them.
Where rules are enforced
Access rules are checked in several places so that what a member sees and what they can actually book stay consistent.
The internal resource list
When a non-admin member views the resource list, the list is filtered so that resources they are blacklisted from, or that they are not whitelisted for, do not appear. Workspace owners and admins are not filtered: they see the full list of resources, with the rules surfaced in the Permissions UI instead.
Booking time
Access is re-checked when a booking is created, not just when the list is displayed. The check always applies to the member the booking is for. If a member, or an admin booking on a member's behalf, attempts to book a resource that member is denied from, the booking is refused. When booking on a member's behalf, the message points to the resource's Permissions tab so the admin can review the whitelist or blacklist entries responsible. Admins cannot silently override a blacklist by booking for the member.
The public website and public checkout
On your public website, resource visibility for anonymous visitors follows the same precedence. Because an anonymous visitor cannot match any member or plan target, any whitelist entry on a resource makes that resource private and hides it from the public entirely. Blacklist entries have no effect on anonymous visitors since there is no specific person to block. If a visitor tries to open a resource that has a whitelist, Deskie returns a not-found result rather than revealing that the resource exists.
For public bookings made by an existing member who is signed in, the same blacklist and whitelist check is applied. A member who is denied from a resource cannot complete a public booking for it, and they receive a generic message that the resource is not available for their account. See Public website and Public sign up and checkout.
Plan targeting and active assignments
When a rule targets a plan, matching depends on the member having an active assignment for that plan at the moment access is evaluated. An assignment counts if it is active and its date window includes the current time: assignments with no start date or a start date in the past, and no end date or an end date in the future, all qualify. If a member's assignment to a plan has ended, they no longer match a plan-targeted rule for that plan, so plan-based whitelist and blacklist entries naturally follow members as they move on and off plans.
Managing rules in the Permissions tab
To work with access rules, edit a resource and open the Permissions tab. There you will find separate Whitelist and Blacklist cards, each with its own Add button that opens a picker. The picker has Members and Plans tabs so you can choose a target. A few behaviors are worth knowing:
- Adding to the blacklist asks for confirmation. Because the effect is immediate and silent, adding a blacklist entry opens a confirmation step where you can also record an optional reason.
- Already-listed targets are hidden in the picker. A member or plan that already has a rule on the resource will not appear again in the picker.
- Adding the same rule twice does nothing. If you add an entry that already exists for the same resource, mode, and target, Deskie treats it as a no-op rather than creating a duplicate.
- Flipping a target between modes is automatic. If a target already has a rule on a resource and you add the opposite mode for the same target, the existing rule is replaced. You do not need to delete the old entry first when moving someone from the whitelist to the blacklist or back.
- Targets come from your whole workspace. The member and plan choices include the workspace's active members and active plans. Rules apply at the resource level, so a resource shared across locations carries the same rules everywhere.
Managing access rules requires the permission to manage resources. For more on who can do what, see Roles and permissions.
Relationship to the resource booking settings
Access rules sit on top of a resource's general member and non-member booking settings, they do not replace them. If a resource has no whitelist or blacklist entries at all, those general settings alone decide who can book. The moment you add any access rule, the precedence above takes over: blacklist entries are denied, whitelists make the resource private to matched members and plans, and when no whitelist applies and the member is not blacklisted, Deskie falls back to the resource's own booking settings.