---
title: "Organizations, roles, and permissions"
description: "How organizations own projects, how roles are granted, and what each role can do."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.heizen.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizations, roles, and permissions

Heizen Studio is organized around **organizations**. An organization owns its
projects; people get access to the organization first, and to individual
projects second. This replaced the older model where a project was owned
directly by the person who created it and invitations happened only at the
project level — organization membership and project membership are now
separate, explicit grants.

## Organization roles

Every person in an organization has exactly one organization role, set when
they're invited from **Members → Invite member**:

| Role | What it means |
| --- | --- |
| **Owner** | Runs the organization. Can do everything an Admin can, plus delete the organization outright. Only an Owner can invite, change, or remove another Owner. |
| **Admin** | Runs the organization: updates organization settings, invites and removes members, connects and manages organization integrations (like GitHub), and can create or delete projects. |
| **Member** | A directory entry. Being a Member of the organization does **not** grant access to any project by itself — project access is a separate grant (see below). |

![The Invite member dialog on the organization Members page, with Email, Role (Member selected), and Job title fields.](/images/heizen-studio/org-invite-dialog.png)

**Owners and Admins are automatically Admins on every project in the
organization** — they don't need to be added to a project's member list to
manage it. A plain **Member** has no project access until someone grants them
one explicitly, either from the organization's **Members** page (assigns a
role on a specific project) or from that project's own **Team Members** tab.

## Project roles

Project access is its own grant, independent of — but combinable with —
organization role. A project role is one of:

| Role | Description | Typical use |
| --- | --- | --- |
| **Admin** | Runs the project. Full control over every project area, including members, invites, environments, API keys, repositories, and the audit log. | Project leads, tech leads |
| **Member** | Works in the project: full read/write access to content (stories, tickets, wiki, meetings, resources...), tests, and integrations. Cannot manage project admin settings — members, invites, environments, API keys, or the audit log. | Everyone actively doing the work |
| **Guest** | Everything a Member can do, with three carve-outs: cannot see or edit internal-only tickets, sprints are read-only (cannot create, update, lock, or unlock them), and cannot start or cancel a Helix agent run — though they can still follow one. | External collaborators — clients, reviewers, contractors |

Guests are invited from the **project's own** Team Members tab, not from the
organization Members page — a Guest is scoped to one project and shouldn't
appear in the organization directory as a full member.

![The Add team member dialog on a project's Team Members tab, with Name or email, Role (Member selected), and Job title fields.](/images/heizen-studio/project-add-member-dialog.png)

When someone has both an organization role and a direct project grant, the
**higher** of the two applies — a project grant can only add access, never
take it away.

## What each project role can touch

Project-scoped data falls into a few groups. Admin can manage all of them;
Member and Guest are limited to the first three:

| Group | Includes |
| --- | --- |
| **Content** | Stories, tasks, tickets and their comments, sprints, wiki pages and folders, canvas diagrams, project resources, meetings, project context, glossary, calendar events, Gmail threads, URL monitoring |
| **Tests** | Test suites, cases, plans, environments, executions, runs, defects, API test steps, VAPT reports, load test specs and runs, unit test reports |
| **Integrations** | The project's connected integrations (linking a repository, connecting Jira, etc.) |
| **Admin-only** | Project members, project invites, linked repositories, environments (secrets), API keys, and the audit log |

A Guest's carve-outs apply on top of this: internal tickets and sprint
writes are blocked even though Guests otherwise sit in the "Member" tier for
content.

## How to reason about access

- **"Can this person see the project at all?"** — Yes if they're an
  organization Owner/Admin, or if they (or their org) has an explicit project
  grant.
- **"Can they change project settings, members, or secrets?"** — Only project
  Admins (which includes every organization Owner/Admin).
- **"Can they load secrets for local development?"** — Yes for every project
  role, through a [developer token](/studio/secrets#developer-tokens-for-local-development).
  Only Admins can view or edit secret values in Studio.
- **"Can they work day-to-day — tickets, stories, tests?"** — Yes for Admin
  and Member; mostly yes for Guest, with the internal-ticket and sprint
  exceptions above.
- **"Can they use the Catalog?"** — Every organization member can browse,
  share, and upvote [Catalog](/studio/catalog) entries. Only an entry's author,
  its contributors, and organization Owners/Admins can edit or delete it.
- **"Can they see who did what?"** — Only project Admins can open the
  [Audit Log](/studio/audit-log).

> **Give the organization role that matches the person's job**
>
> Reserve organization Owner/Admin for people who should manage every project
> in the organization. Most contributors should be an organization Member with
> an explicit Member or Admin grant on the specific projects they work in.

> **Personal account settings are separate**
>
> A few things are never role-based: everyone can manage their own account,
> their own personal Calendar/Gmail connections, and personal recordings not
> yet attached to a project. See [Account settings](/studio/account).

Source: https://docs.heizen.work/studio/permissions/index.mdx