--- title: "Permissions" description: "Decide which teams and people may create, share and publish assistants, projects, automations and more" canonical_url: "https://meingpt.com/en/docs/admin-guide/permissions" language: en --- # Permissions With **Permissions** you decide per team or person who in the workspace may build and distribute things: assistants, projects and workflows, automations, API keys, custom MCP servers, meetings and chat links. That way you open up building to the departments without giving up control over what reaches the whole workspace. **Workspace admins are never restricted** — they can always do everything. ## Availability Permissions are enabled per workspace by MeinGPT support. Contact support to enable permissions for your workspace. Until the feature is enabled, everything behaves as before. Afterwards, as a workspace admin you find the page under **Settings → Workspace → Permissions**. Even once enabled, nothing changes until you set a rule: without a rule of your own, each permission keeps its default (see below). ## What you can control The page is grouped by area. Each row is one permission with its default: | Permission | Default | Note | | --- | --- | --- | | **Create assistants** | Everyone | | | **Share assistants** | Everyone | | | **Publish assistants to everyone** | Admins only | Elevated, licensed members only | | **Create projects** | Everyone | Licensed members only | | **Share projects** | Everyone | Licensed members only | | **Publish projects to everyone** | Admins only | Elevated, licensed members only | | **Create workflows** | Everyone | Licensed members only; editing rights in the project are also required | | **Create automations** | Everyone | | | **Create API keys** | Everyone | Elevated, licensed members only | | **Add custom MCP servers** | Everyone | Elevated | | **Share meetings** | Everyone | Also covers automatically sharing bot recordings with attendees | | **Publish meetings to everyone** | Admins only | Elevated, licensed members only | | **Share chats via link** | Everyone | Link through which colleagues in the workspace can read a chat | - **Licensed members only:** [Viewers](/en/docs/admin-guide/roles-and-access-model) without a seat never get this permission, whatever rule applies. - **Elevated:** these permissions cannot be given to teams with team admins — see [Team admins](#team-admins). Anyone without a permission sees the matching button disabled with the hint “Not enabled by your admin”. ## Setting a permission Click the button with the current setting in the row (e.g. “Default: Everyone”). In the dialog, choose under **Availability**: - **Default** — no rule of your own, the default applies. - **Everyone** — every member may do this. You can exclude individual people. - **Admins only** — only workspace admins and the people you add. - **Only selected teams** — only the teams and people you add. - **All except** — everyone except the teams and people you add. You add individual people as an **Exception** and set them to **Allowed** or **Blocked** — for example “All except apprentices, but Max may”. ### How several teams combine - **A person exception always wins.** It applies regardless of the person's teams. - **Only selected teams:** it is enough for the person to be in **one** of the selected teams. - **All except:** it is enough for the person to be in **one** of the excluded teams — they are then blocked, even if they are also in other teams. - The default team contains every member of the workspace. Selecting it makes the rule apply to everyone. Before you save, the dialog shows the impact: how many members may do this afterwards, how many lose it and how many gain it (admins not counted). ## Sharing vs. publishing to everyone For assistants, projects and meetings, MeinGPT distinguishes two reaches: - **Share** — with individual people and with teams you are a member of yourself. - **Publish to everyone** — with the whole workspace, the default team or teams you are not a member of. Anyone who may publish may also share — the “share” row shows this with the hint “Included in …”. Exception: if a person is explicitly blocked from sharing (as a person exception or through a team under **All except**), they may not publish either. For projects: raising the role of a member or team in a project needs the same permission as sharing. **Editing published assistants and projects:** once an assistant or project is published to everyone (shared with the whole workspace or the default team), only people who may also publish to everyone can edit it. That way nobody can rework something everyone uses without being allowed to publish it. Admins always can. ## Team admins Whoever maintains a team's members co-decides who gets that team's permissions. That is why teams with team admins follow these rules: - **Standard permissions** (create, share) can also go to teams with team admins. The dialog points out that the team admins co-decide. - **Elevated permissions** (publish to everyone, API keys, custom MCP servers) and **All except** **cannot** go to teams with team admins. Pick people directly instead, or a team whose members only workspace admins maintain — e.g. a dedicated team “Marketing – Publishing”. - A team carrying such rules cannot get team admins while the rules exist. Teams used in a rule cannot be deleted and cannot be switched between “Accessible for everyone” on and off. Remove the team from the rules first. ## Checking a person's permissions Under **Settings → Workspace → Members**, the shield icon in a person's row opens **Permissions of …**. It shows for each permission whether the person has it — and why, e.g. “Allowed through team Sales”, “Personal exception” or “Needs a license — this person has none”. You change this on the **Permissions** page. Every change to a permission is recorded in the [audit log](/en/docs/admin-guide/compliance-controls). ## When someone loses a permission - Anyone who loses a **create** permission keeps the assistants, projects or automations they already created. - Anyone who loses **share** or **publish** can no longer share anew. Existing shares remain. - **Personal API keys** stop working as soon as their owner may no longer **Create API keys**. ## Recommended setups ### Small team Keep all defaults. Everyone may build and share, only admins publish to everyone. You don't need to set anything. ### Rollout by department Set **Create assistants** and **Create projects** to **Only selected teams** and pick the departments that start first. Add more teams as they join. Sharing stays open to everyone, publishing to everyone stays with the admins. ### Centrally governed Keep **Publish to everyone** on **Admins only** and add your AI champions as person exceptions set to **Allowed** — or create a team for them that only workspace admins maintain. If needed, also set **Create API keys** and **Add custom MCP servers** to **Admins only**. ## Related - [Releasing a model to specific teams or people](/en/docs/admin-guide/workspace-configuration#releasing-a-model-to-specific-teams-or-people) — the same principle for AI models. Under **Settings → Image models** you decide the same way who may use which image model; the default image model always stays available to everyone. - [Roles & Access Model](/en/docs/admin-guide/roles-and-access-model) — admin, member and viewer - [Teams & Groups](/en/docs/admin-guide/team-management) — create and maintain teams