Roles and Permissions

Seatsurfing controls who may do what through roles. A role is a named set of permissions that an organization administrator defines, and every user can hold any number of them.

How access is decided

A permission names one functionality — users, groups, areas, the audit log — and a role grants each of them at a level:

Level	Meaning
No access	The functionality is not available, and it does not appear in the administration interface.
Read only	The user can see the records but not change them.
Limited	The user can make a restricted set of changes. Currently used only for group membership.
Full access	The user can create, change and delete records.

Where a user holds several roles, the highest level any of them grants wins. Granting Read only in one role and Full access in another results in full access.

Not every level is meaningful for every functionality, so each one offers only those that are. "Areas", for instance, offers no read-only level, because every user can already see the areas and spaces they are able to book.

What every user can always do

Some things are not governed by permissions at all, because without them the booking interface could not work. Every user, holding no roles whatsoever, can always:

• create, view, change and cancel their own bookings, including recurring ones
• manage their buddies and their own preferences
• change their own profile, password and multi-factor authentication
• see the areas, spaces and availability they are allowed to book

Roles govern administrative access on top of this baseline. They never take it away.

The permissions

Permission	Levels	Covers
Areas, floor plans and spaces	none, full	Locations, floor plans, maps, spaces, approvers and allowed bookers
Attributes	none, full	Space and location attributes
Bookings of other users	none, read, full	Seeing and managing bookings that belong to other people, and booking on their behalf
Booking approvals	none, full	Approving bookings that require it
Utilization statistics	none, read	Aggregate occupancy figures and the dashboard tiles
Presence report	none, read	Who was present and when — personal data, so separate from the aggregate figures above
Users	none, read, full	Creating and changing users, resetting passwords and second factors
Groups	none, read, limited, full	Limited grants management of group membership only; Full access adds creating and deleting groups
Roles and permissions	none, read, full	Defining roles and assigning them
Service accounts and API tokens	none, full	Creating service accounts and issuing API tokens
Authentication providers	none, full	OAuth2 and OIDC identity providers
Organization settings	none, full	Booking settings, organization profile, domains
Audit log	none, read	The record of authentication attempts

Plus features and cloud features contribute their own permissions — Exchange, SCIM, Microsoft Teams and the subscription screens each have one — and they appear in the role editor alongside the list above whenever those plugins are installed.

The built-in roles

Every organization starts with three roles:

• Organization Administrator — full access to everything. This role cannot be edited or deleted, so that an organization always retains a way to administer itself.
• Floor Plan Administrator — full access to areas, spaces, attributes, bookings and approvals; read access to analysis, users and groups.
• API access — the permissions a service account needs to call the REST API.

Apart from the first, these are ordinary roles. Edit or delete them freely; they are a starting point, not a fixed part of the system.

Example: a role that only manages groups

To let someone maintain group membership without giving them anything else:

1. Go to Roles and click Add.
2. Name the role, for example Group Coordinator.
3. Set Groups to Limited — membership only — or Full access if they should also create and delete groups.
4. Leave every other permission at No access.
5. Save, then open the user under Users and tick the new role.

That user now sees only Groups in the administration interface. Everything else answers with "forbidden", whether they reach it through the interface or call the API directly.

Organization-wide restrictions

Two settings under Settings sit above the permissions entirely:

• Disable user-related reports withholds the presence report
• Disable utilization statistics withholds the aggregate figures

These apply to everyone, including whoever holds the Organization Administrator role. That is the point: a permission is something an administrator can grant themselves, so it cannot express "nobody here evaluates presence data" — which is exactly what a works council agreement may require. The settings can express it.

They are not a security boundary — anyone who can change organization settings can switch them back — but doing so is a single deliberate act rather than a side effect of editing a role. Where both apply, the restriction wins: holding the permission does not get you past the setting.

Not locking yourself out

An organization must always keep at least one enabled user who can manage both roles and users. Seatsurfing enforces this rather than trusting you to notice:

• The Organization Administrator role cannot be edited or deleted.
• A change that would leave the organization without an administrator — deleting the last one, disabling them, or weakening the only role that grants administration — is refused.
• You cannot remove your own ability to manage roles.
• Nobody can grant access they do not hold themselves. An administrator who cannot see the settings cannot create a role that can.

If an organization somehow ends up without an administrator — a database restored from a partial backup, say — Seatsurfing repairs it at start-up by granting the Organization Administrator role to one of its users, and writes a warning to the log saying so.

Assigning roles automatically

Where users sign in through an OAuth2 or OIDC identity provider, roles and group memberships can be assigned from a claim in the token, so that access is managed centrally in the provider rather than separately in Seatsurfing. See Auth Providers.

Service accounts

A service account is not a role but an account type: it calls the REST API and cannot sign in to the web interface. Service accounts are assigned roles like anyone else, so an API token can be scoped to exactly what it needs. Read-only service accounts are additionally restricted to GET requests, whatever their roles say.

See Users for how to create one and issue its token.