Roles and Permissions for Room, Desk, and Parking Booking: How to Get Access Right

What is a permissions model, and why does resource booking need one?

Who gets to manage rooms, analyze booking data, or book on behalf of others? The bigger a company gets, and the more locations, legal entities, and areas of responsibility it has, the harder that question is to answer. A good permissions model doesn’t try to give as many answers as possible. It gives the clearest ones.

In a small company, assigning permissions is usually still manageable. A handful of employees book desks and rooms, and a few people handle administration. But once you add multiple locations, business units, legal entities, or distinct areas of responsibility, a simple model quickly hits its limits.

Should the site admin in Munich be able to edit rooms in Hamburg? Should managers be able to see individual employees’ bookings? Who manages the use of special-purpose spaces? And does someone with admin duties automatically need access to personal data?

The seemingly simple question of “Who can do what?” quickly becomes a fundamental organizational challenge.

Gingco Share solves it with a dedicated roles and permissions model built on the need-to-know principle. With more than 150 individual permissions, you can restrict access across three core pillars: users, objects, and locations.

But technology is only part of the solution. What really matters is how permissions are structured so they stay clear, maintainable, and adaptable as your organization changes.

The three dimensions of a permissions model: for whom, for what, and where

Many permissions models start out very simple: employees can book, admins can manage. In more complex organizations, that setup no longer works. A site manager may need extensive management rights, but only for their own location. An assistant should be able to book for specific people without being able to change the system configuration. And central admins need system-wide functions without automatically gaining visibility into personal data.

This is where a professional permissions model comes in. It doesn’t just answer which functions someone can use and which role they hold, but also:

1. For whom?
   Which users or user groups does the permission cover?
2. For what?
   Which objects or object groups can be managed?
3. Where?
   Which locations, buildings, or areas does the permission apply to?

Gingco Share combines these three dimensions with custom roles and permission groups. That lets you tailor permissions precisely to specific tasks and build them around areas of responsibility.

Need-to-know and least privilege: why too many and too few permissions both hurt

Every permissions model has to steer clear of two opposite risks:

Too few permissions get in the way of everyday work. Employees can’t complete tasks on their own, constantly need help from admins, and processes become needlessly complicated.

Too many permissions, on the other hand, increase the risk of user errors and unnecessary access to sensitive information.

So the challenge isn’t to be as restrictive or as generous as possible. It’s to grant exactly the permissions a specific task requires. That’s the principle of least privilege, or need-to-know: employees only get access to the system areas, functions, and information they need to do their jobs.

That way, roles and permissions aren’t an obstacle, but an important security mechanism. They reduce user errors, limit unnecessary access, and keep responsibilities clear, even in larger organizations.

Permissions model example: a role matrix for a company with 8 locations

Let’s take a company with:

• 8 locations
• a central facility management team
• local site managers
• executive assistants
• multiple legal entities
• different resources, such as desks, rooms, and parking spaces

A global admin permission would be easy to set up, but it would give local managers access to areas they aren’t even responsible for.

That’s why it makes more sense to separate responsibilities:

These are exactly the kinds of organizational boundaries the Gingco Share roles and permissions model is designed to reflect. Management rights can be limited to locations, buildings, areas, object groups, or individual objects, for example. Booking on behalf of employees, teams, external guests, or executives can also be controlled through the appropriate roles.

Role-based access control: roles instead of individual permissions

In theory, every permission could be assigned to every person individually. But in a company with hundreds or thousands of employees, that would be almost impossible to manage over time. That’s why individual permissions are bundled into roles, also called permission groups.

Gingco Share provides predefined global, local, and functional permission groups that you can customize and extend. Individual permissions can be moved between groups or combined into new roles. You can also build a hierarchy: higher-level roles inherit the permissions of the groups below them and add more on top.

This turns a long list of one-off decisions into a structured model. Instead of “Person A gets permissions 17, 22, 43, 65, and 84,” the organizational decision becomes, for example: “Person A takes on the role of ‘Local Site Admin, Braunschweig’.”

That’s easier to understand, easier to trace, and above all, easier to maintain.

Assigning roles automatically: permissions that follow your organization

The next challenge comes as soon as the company changes. An employee moves to another department. A site manager takes over an additional building. Someone leaves the company. A new subsidiary is integrated.

If these changes have to be replicated manually in your resource management software, keeping things up to date quickly turns into an ongoing headache. That’s why Gingco Share can assign and revoke roles based on rules, using a range of attributes such as department, Active Directory group membership, cost center, location, or other custom attributes supplied by source systems.

Employee, organizational, and location data can be imported and synced centrally from existing services, identity providers, or HR systems. That way, organizational changes flow automatically into user and role management.

Onboarding and offboarding: permissions when people join, move, or leave

This matters most during onboarding and offboarding.

• Onboarding: A new employee is created in the leading system and receives the roles and access rights that match their place in the organization.
• Internal moves: If someone’s department, location, or area of responsibility changes, their permissions can change along with it.
• Offboarding: When someone leaves, their permissions are revoked. You can also define when a user account is deleted and how existing bookings should be handled.

This doesn’t just reduce administrative effort. It also lowers the risk of old permissions quietly lingering after a role change or departure.

Managers and admins: more responsibility doesn’t mean more data access

A common misconception about permissions: the higher up you are in the hierarchy, the more you automatically get to see.

For a privacy-first permissions model, that’s exactly the problem. A leadership position or high security clearance doesn’t automatically justify access to personal booking information. Access to sensitive information can be limited to the user groups that actually need it and are allowed to have it.

So the principle is simple: access isn’t determined by hierarchy, but by task, purpose, and authorization.

A GDPR-compliant permissions model: involve data protection and the works council from day one

A roles and permissions model isn’t just about IT security. Desk, room, and resource bookings in particular can involve processing personal data.

That’s why these questions should be settled early on:

• Who can see personal booking information?
• Which reports and analyses are permitted?
• What data does a role actually need?
• How long does information remain personally identifiable?
• When is it anonymized or deleted?
• What does the works agreement stipulate?

To support this, Gingco Share offers role-based access, configurable retention and deletion rules, and anonymized occupancy and usage data, utilization analytics, and statistics. Reporting options can be controlled based on your configuration and internal policies.

Within the framework of the relevant codetermination agreements, employees can also decide for themselves who gets to see their own booking data.

Multi-tenant permissions for corporate groups with multiple legal entities

Permission management gets especially demanding in enterprise environments. Multiple legal entities may share the same booking system but need to keep their resources and data organizationally separate. Central teams need cross-entity functions, while local managers should only be able to manage their own region.

Gingco Share can separate permissions by legal entity, business unit, and organizational unit, which means it can also map group-wide structures spanning multiple locations and countries.

For example, you could set up a model in which:

• group-level administration manages global master data,
• country organizations administer their own locations,
• local teams manage individual buildings,
• subject-matter owners only edit specific resource types, and
• employees only see and book the resources made available to them.

A permissions model that grows with your organization and scales with your business.

How to build a permissions model: 10 things it needs to cover

Before setting up permission groups on the technical side, it pays to step back and look at the big picture. At a minimum, a solid permissions model should cover:

1. Goals: What risks and organizational requirements should the model address?
2. Roles: What recurring tasks and responsibilities are there?
3. Permissions: What functions does each role actually need?
4. Scope: Which users, locations, and objects do these permissions apply to?
5. Ownership: Who can assign, change, and revoke roles?
6. Automation: Which roles can be assigned automatically based on organizational attributes?
7. Special permissions: Which exceptions are necessary, and who approves them?
8. Data protection: Who can view and analyze personal data?
9. Lifecycle: What happens when someone joins, moves internally, or leaves?
10. Traceability: How are administrative changes documented?

Answer these questions before years of ad hoc individual permissions snowball into a model no one can keep track of.

Roles and permissions in Gingco Share: key features at a glance

Employees, assistants, site managers, or central administration: with clearly defined roles and permissions, you create clear lines of responsibility and stay on top of even complex structures. Gingco Share combines granular permission management with organizational restrictions and automation.

Key building blocks include:

• More than 150 individual permissions, which can be assigned to different roles and permission groups
• Restrictions based on the three core pillars: users, objects, and locations
• Global, local, and functional permission groups
• Hierarchical roles with permission inheritance
• Rule-based automatic assignment and revocation of roles
• Integration with existing identity providers and HR systems
• Automated onboarding and offboarding processes
• Separation by legal entity, business unit, and organizational unit
• Controlled access to personal data
• Configurable anonymization and deletion of booking data

Checklist: review your roles and permissions model before rollout

Before you configure roles, make sure you’ve answered these questions:

• Tasks: What recurring responsibilities are there?
• Necessity: Which permissions does each role really need?
• Users: Which people or groups can a role act on behalf of?
• Objects: Which resources can it view, book, or manage?
• Locations: Do permissions apply locally, regionally, or globally?
• Legal entities: Do business units or tenants need to be kept separate?
• Personal data: Who actually needs access to it?
• Automation: Which roles can be derived from Active Directory, HR, location, or cost center data?
• Onboarding/offboarding: How are permissions adjusted automatically when people join, move, or leave?
• Special permissions and roles: How are exceptions granted and reviewed?
• Works council and data protection: Which requirements need to be implemented on the technical and organizational side?
• Audit trail: How do you keep changes to admin permissions traceable?