# Understand your workspace, roles and rights

<Lead>
Everything on the platform belongs to exactly one **workspace**: your office. This page explains what a workspace is, which roles exist and how permissions work. With that, every rights question you meet in the tools makes sense.
</Lead>

## What is a workspace?

A workspace is your office's self-contained area: its own data, its own team, its own tool selection, its own branding.

- **Own address:** from the first paid plan your workspace runs under its own subdomain (for example `myoffice.reosa.de`), later optionally under your [custom domain](/help/howto/custom-domain). During the trial you use the central address; your preferred subdomain is reserved.
- **Strict separation:** every data row belongs to exactly one workspace and is isolated at the database level. Another workspace technically cannot see your data, not even by accident.
- **White-label mindset:** the workspace's name, logo and colors are yours. Towards your clients, the platform stays in the background.

## The four roles

<DefinitionList>
  <DefItem term="Owner">
    The person the workspace belongs to. Can do everything, including billing, plan changes and the things nobody else may do. There is exactly one owner role per workspace.
  </DefItem>
  <DefItem term="Admin">
    Full day-to-day administration: all settings, team management, billing, all tools. Recommendation: at most two or three admins per office.
  </DefItem>
  <DefItem term="Member">
    The default role for team members who work independently: use all activated tools, create and manage their own entries. No team or billing administration.
  </DefItem>
  <DefItem term="Observer">
    Read-only access, no tool runs and no changes. A fit for back office, interns or external reviewers.
  </DefItem>
</DefinitionList>

How to create accounts, assign roles and manage seats: [Staff accounts](/help/howto/invite-members).

## How permissions work

Three rules explain almost every rights behavior on the platform:

<Steps>
  <Step title="Roles carry sensible defaults">
    Every role comes with a sensible set of default permissions. A member can, for example, create and share entries in the credentials vault, but not change the team's vault policy.
  </Step>
  <Step title="Tools bring their own permissions">
    Every tool defines finer rights (for example "configure appointment booking" or "permanently delete files"). What each role may do is listed in the tool guides in their roles-and-rights sections.
  </Step>
  <Step title="Everything is checked twice">
    The interface hides what you may not do, and the server independently re-checks every action. Making a hidden element visible through tricks therefore never grants extra rights.
  </Step>
</Steps>

<Info title="Some content is personal instead of role-based">
A few areas belong to the person, not the workspace: the private "My files" area in the file storage, personal entries in the credentials vault, or the assistant's personal memory. Even admins do not see this content day to day.
</Info>

## Typical questions

<Faq>
  <FaqItem q="Why do I not see a menu item my colleague sees?">
    Almost always a role or permission question: the area is hidden for your role. An admin can check your role under Settings > Members.
  </FaqItem>
  <FaqItem q="Can I grant someone individual rights instead of a whole role?">
    The role sets the base package. Finer grants exist where content is shared, for example folder access lists in the file storage or shares in the credentials vault.
  </FaqItem>
  <FaqItem q="What happens to content when someone leaves the team?">
    Workspace content is preserved; only the person's access ends. Personal areas have managed handover paths (for example orphaned "My files" areas the owner can take over).
  </FaqItem>
</Faq>