Reviewing access controls in a workspace booking tool

“Can see” and “can book” are different permissions. A member may need to see that an event room exists without being allowed to reserve it, while a manager may need to book it on someone else’s behalf. Map those roles before opening a booking portal.

Build a small access matrix for members, day-pass visitors, reception staff and administrators. For each role, test whether they can view availability, see booking details, create a reservation, override a rule, change someone else’s booking and export member information. Use a test account for each role; an admin view will hide many problems.

Skedda documents conditions that restrict booking by user tag, space and time, while system users can bypass those conditions. Cobot’s external-booking feature is an add-on for non-members. OfficeRnD Flex documents approval policies and admin-created bookings outside member rules. Treat these as specific controls to investigate, not as proof that every role is configured safely by default.

Check the information displayed alongside a reservation. Members usually need to know that a room is occupied, not the meeting topic or another member’s contact details. Separate public availability from private booking information.

Review former members’ access and staff permissions after role changes, and make someone responsible for granting exceptions.

The practical acceptance test is this: each role can complete its legitimate booking task, and cannot use the same interface to change or inspect a reservation outside its remit.

Key Access Control Metrics