A permissions concept is not a box-ticking exercise but a decision about scope and effort. teamspace gives you the full range – from “everyone may do almost anything” to a finely granulated role model. This article is aimed at management, IT leads and data protection officers, and helps you choose the right level before anyone starts configuring.
How much control do you really need?
The guiding principle of teamspace is: everyone sees and does only what they need for their job – the simpler, the better. But more control also means more maintenance effort. Weigh up along these questions:
- Sensitive data: Is there data not everyone may see (salaries, contracts, certain customers, steering committee projects)? → Protection classes and operation rights are worth it.
- Size & locations: Is it 15 people at one site, or 400 across several? → Above a certain size, group hierarchies and group-specific visibilities pay off.
- Compliance: Do data protection, your industry or a certification require documented access? → A clear role model is then not optional.
- Onboarding frequency: Do new employees or temporary staff join often? → Roles with “New users automatically members” and default project roles save a lot of time.
Starting small is legitimate. You can begin with a few roles and let the model grow. teamspace forces nothing on you – the concepts are there when you need them.
Four guidelines for a maintainable concept
- Roles, not people. User groups represent functions (
HR,Finance,Management), not bundles of individuals. Members change, the rights remain. This is the single most important lever for maintainability over the years. - Separate what belongs apart. Team groups for project setup carry no rights; the rights are distributed in parallel by the functional roles. That way “who works together” does not get mixed up with “who may do what”.
- Hierarchy only where it helps. Map locations and departments through inheritance, and special roles as hidden user roles – but not every constellation as its own visible group, or the list becomes unwieldy.
- Put security above shortcuts. Clerk rights and the user switch are powerful – grant them sparingly and deliberately, not as a convenient shortcut.
The concrete implementation of these guidelines is covered in Group hierarchies, inheritance & user roles.
Safeguards that must not be missing
- At least one tenant admin. Otherwise you risk a situation where no one can grant rights back (see Tenant admin & not locking yourself out).
- Keep the user switch a small circle. Anyone allowed to switch into other accounts can act in their name – this belongs to administrators, and at most temporarily to HR/management.
- Oversight via the central Group permissions tab. Here you see at a glance who may carry out which personal operations – a good starting point for a regular review.
The building blocks at a glance
| Building block | What for | |
|---|---|---|
| Six permission levels | Visibility of menu, tabs, actions, search, configuration | Six levels |
| User groups | Bundles of rights + members (roles) | User groups |
| Hierarchies & roles | Locations, departments, hidden special roles | Group hierarchies |
| Group-specific rights | Personal matters (visibility, leave, travel costs) | Group permissions |
| Element level | Project roles, protection classes, clerks | Element permissions |