> ## Documentation Index > Fetch the complete documentation index at: https://docs.get-hive.ai/llms.txt > Use this file to discover all available pages before exploring further. # Roles and permissions > The five Hive roles — Owner, Admin, Department lead, Operator and Analyst — what each can see, approve and change, and how department scope works. Every member of a Hive workspace has exactly one **role**. The role decides what they can see, which proposals they can approve, and which settings they can change. Roles are ranked, so each role can do everything the roles below it can, plus more. ## The five roles | Role | Short description | Typical person | | - | - | - | | **Owner** | Full control | The founder or managing partner | | **Admin** | Manage workspace | Operations lead, IT administrator | | **Department lead** | Run a department | Head of Finance, Head of Sales | | **Operator** | Do the work | Team members who act on signals and run workflows | | **Analyst** | Read-only | Stakeholders who need visibility, not control | In the product's data the Analyst role is called `viewer`. You may see that name in exports or support conversations. ## What each role can do | Capability | Owner | Admin | Department lead | Operator | Analyst | | - | :-: | :-: | :-: | :-: | :-: | | See signals, the Brain and the audit trail in scope | ✓ | ✓ | ✓ | ✓ | ✓ | | Act on, snooze and dismiss signals | ✓ | ✓ | ✓ | ✓ | — | | Approve proposals | up to **B4** | up to **B4** | up to **B3** | up to **B2** | — | | Run workflows and agents | ✓ | ✓ | ✓ | ✓ | — | | Create agents in Agent Studio | ✓ | ✓ | ✓ | — | — | | Activate learned behaviours | ✓ | ✓ | ✓ | — | — | | Change policy, autonomy and the kill switch | ✓ | ✓ | — | — | — | | Enable connectors for the workspace and add channels | ✓ | ✓ | — | — | — | | Invite, remove and change members | ✓ | ✓ | — | — | — | | Manage billing | ✓ | ✓ | — | — | — | | Scope | All departments | All departments | Selected departments | Selected departments | Selected departments | ### Approval tiers Every proposed action carries a **blast-radius tier** from B0 to B4. The tier sets how senior the approver must be. | Tier | Meaning | Examples | | - | - | - | | **B0** | Invisible or reversible | Update a fact, write a draft | | **B1** | Internal-facing | Post in Slack, create a task | | **B2** | External, cheap to fix | Email a known contact | | **B3** | External, hard to reverse | Message a key client, send in bulk | | **B4** | Money, legal or irreversible | Issue a refund, revoke access | When a proposal is above your tier, the review panel tells you it "is above your access — this routes to" the role that can approve it. Analysts see exactly why Hive proposed something, but only Operators and above can act. See [Autonomy and blast radius](/approvals/autonomy-and-blast-radius) for how tiers interact with autonomy. ## Department scope Owners and Admins always see the whole business. Hive's role model also has department scope for Department leads, Operators and Analysts (Finance, Sales, Marketing, Customer Success, People, IT & Security), but you can't choose a member's departments yet: invites don't ask for them, and nobody can switch departments. ## Preview a role On a workspace that shows sample data (no identity provider connected), Owners and Admins can preview the product as another role from **Roles & access** with **Preview as …**. A banner reads "Previewing as …" while the preview is on, and **Exit preview** returns you to your own view. Use it to check what a new Analyst will actually see. Signed-in workspaces do not offer preview, because a local preview would not reflect real permissions. ## Connectors and roles Connectors use a two-step model: 1. **An Owner or Admin enables a provider** for the workspace. Connecting it yourself as an admin enables it automatically. 2. **Any member can then connect their own account** for that provider. Until a provider is enabled, members see "A workspace administrator must enable this provider before you can connect a personal account." Connected accounts belong to the person who connected them. Owners and Admins can see which connections exist in the workspace, but not anyone else's credentials, scopes or actions. Setting an account's autonomy level (Read, Draft, Act) is an admin task. See [Accounts and autonomy](/integrations/accounts-and-autonomy). ## Workflows and agents: per-item access Workspace roles decide *whether* someone can run or build. Each workflow and agent also has its own sharing: | Item access | Lets a teammate | | - | - | | **Can view** | Open the item and read its configuration and runs | | **Can run** | Run it with their own connected accounts | | **Can edit** | Change and deploy it | Running still requires the Operator role or above. Admins and Owners can read every workflow and agent in the workspace, even ones not shared with them, but cannot run or edit one they have not been given access to. See [Share and reuse](/workflows/share-and-reuse). ## Rules that protect the workspace * **No self-edit** — you cannot change your own role. * **No escalation** — you cannot grant a role higher than your own. * **Last Owner** — the final Owner cannot be demoted or removed. * **Fail closed** — if Hive cannot confirm your role, you get the most restrictive view, not the most permissive. ## Frequently asked Keep Owners to the people accountable for the business — usually one or two. Owners and Admins share almost every capability, so most administrators should be Admins. Operators can pause learned behaviours and work with the knowledge Hive holds. Activating a proposed behaviour so Hive uses it needs a Department lead, Admin or Owner. See [Learned behaviours](/brain/learned-behaviours). Not today. Hive uses the five fixed roles above, combined with department scope and per-item sharing. ## Related Invite, change and remove members. How approvals work in practice. Policy, kill switch and spend caps. How Hive enforces access behind the scenes.