> For the complete documentation index, see [llms.txt](https://herd-security.gitbook.io/herd-security-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://herd-security.gitbook.io/herd-security-docs/how-to-documentation/managing-roles-groups-and-permissions.md).
# Managing Roles, Groups, and Permissions
How to control who can do what in your Herd workspace using roles, groups, and permissions.
***
### Understanding app access
In Herd, whether someone has the app is a setting on the person, and what they can do comes from the groups they're in. There are no separate roles to manage.
| Who | What they get | How they get it |
| -------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Admin** | Full access to everything in your Herd workspace, including who else has access. | Being in the **Full Access** group. |
| **People in another group with permissions** | The app, with exactly the permissions their groups grant. | Being in **Operators**, **Reviewer**, or a group of your own that grants at least one permission. |
| **Learner** | Can sign in to Herd and see their own training, with no admin permissions. | Having the app without being in any group with permissions. |
| **Everyone else** | No app. They take trainings and respond to simulations through Slack, Teams or email. | Not having been given the app. |
The Users table and the account menu name the group(s) that give each person permissions, with an admin badge for admins.
{% hint style="info" %}
The first person to sign in to an organization with no admin becomes the admin. After that, everyone in your organization who signs in gets the app as a learner, unless your identity provider decides who gets it (see [App Access](/herd-security-docs/users/users/app-access.md#who-gets-app-access-when-they-sign-in)). An admin gives or removes one person's access from their page with **Give app access** or **Remove app access**. Until there's a second admin, the **Get Started** checklist says *You are the only admin. Add your team to Full Access.*
If you want new people to start with some permissions, set a **default group** on **Settings → General → Access → Access groups** (see [The default group](/herd-security-docs/settings/settings/access.md#the-default-group)). Out of the box there's none.
{% endhint %}
#### Who is an admin
An admin is anyone who holds **Manage admins and permissions** (`org.permissions`). The **Full Access** group holds every permission, including that one, so everyone in Full Access is an admin:
* Add a person to **Full Access** to make them an admin, from the group or from the **Groups** button on their profile. This gives them the app, and a seat, if they don't have it.
* Remove them from **Full Access** to stop them being an admin. They keep the app, with whatever their other groups allow, or as a learner.
* Your organization can never lose its last admin. Herd refuses to remove them, and if an identity-provider sync tries to, Herd keeps the person and alerts your admins (**Kept your last admin**).
* **Full Access** can't be deleted. If it is ever missing, Herd recreates it.
#### App seats
Depending on your plan, your organization may have a set number of **app seats**, shared by everyone with the app (admins, people in your permission groups, and learners). Contact your Herd team if you're not sure whether a limit applies to you.
Where there is a limit, once every seat is taken, a new web sign-in still works but the person sees only their own training, and an admin can't give anyone else the app (with **Give app access**, or by adding someone without the app to a group with permissions) until a seat frees up. A directory rule sync or SCIM group push gives the app while seats last and skips the rest, and Herd alerts your admins. Restoring a removed user, whether by hand, through SCIM or from a directory sync, brings them back without the app; they get a seat back at their next sign-in or from an admin, if one is free. Organizations already over their cap keep everyone they have: the cap only stops new seats.
***
### Understanding Groups
Groups are how you organize people and give them permissions. Think of groups like teams — each group has a set of permissions, and everyone in that group inherits them.
* Each group has a **name**, **description**, and a **set of permissions**
* A person can belong to **multiple groups** — their permissions are the combined set from all groups
* A group that grants at least one permission is an **access group**. Adding someone without the app to one gives them the app (and takes a seat); leaving it doesn't take the app away. A group can't be given its first permission while it has members without the app; give them app access first, or remove them
* On **People → Groups**, the **Access groups** filter narrows the list to these groups (`/users/groups?access=1`). A person's **Groups** button on their profile lists their groups, marks access groups, and, with **Manage groups**, lets you add them to a group or remove them from one
* If you've set a **default group**, people who get the app are added to it automatically
* Groups can pull members from **Okta**, **Azure AD** or **Google Workspace** to mirror your existing team structure (Slack user groups are retired). Herd's managed groups are the exceptions: they can't have a membership rule, so add their members one by one
* Only a group without a membership rule can hold permissions: pick its people, or sync them from your identity provider. A group with conditions can't be given a permission, and a group with permissions can't be given conditions, so a rule never hands anyone a permission nobody granted
* Herd creates three groups in every organization and marks them **Managed by Herd** on the Groups page:
| Group | Permissions |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Full Access** | Every permission (admins) |
| **Operators** | Every permission except **Manage admins and permissions**, for people who run day-to-day security awareness |
| **Reviewer** | View access to trainings, tracks, simulations (email, SMS, WhatsApp and voice), compliance, policies, people, groups, AI governance, GitHub integration and nudges, plus the reporting dashboard and risk scores, **Use Herd AI**, and **Comment on trainings**: they see everything and change nothing |
Their names and permissions are fixed, and they can't be deleted. If your organization already had a group with one of these names, or your identity provider later pushes one over [SCIM](/herd-security-docs/settings/settings/scim-provisioning.md#guardrails), Herd's is called, for example, **Operators (Herd)**. Opening one shows the badge, its description, a one-line summary of its permissions, and *Managed by Herd: its name and permissions are fixed. Members are yours to change.* To give someone a different set of permissions, add them to another group. (An Operators member can add people to groups, but not to a group that grants more than they hold.)
Herd used to manage a **Learners** group too. If you had one, it's now an ordinary group of your own with the same members; it no longer has any effect on access.
{% hint style="warning" %}
If you make **Full Access** the default group, **everyone who gets the app becomes a full admin**, able to manage admins and permissions, network access and announcements as well as everything else. Leave the default group empty, or pick a group with fewer permissions, unless everyone should be an admin.
{% endhint %}
***
### Setting Up Groups
#### 1. Plan Your Access Structure
Before creating groups, decide who needs access to what.
{% tabs %}
{% tab title="Small Team" %}
Keep **Full Access** for your admins and leave the default group empty, so everyone else who signs in is a learner and sees only their own training. Everyone in Full Access can do everything, including managing users, settings, and other admins.
{% endtab %}
{% tab title="Department-Based" %}
| Group | Recommended Template |
| --------------------------------------------------------------------------- | -------------------- |
| **Security Team** — Full phishing, smishing, training, and reporting access | Security Manager |
| **HR / Training Team** — Training creation and assignment only | Training Manager |
| **Compliance Team** — Compliance campaigns and policies | Compliance Manager |
| **Leadership** — Read-only dashboards and reports | Viewer |
| {% endtab %} | |
{% tab title="Least-Privilege" %}
Create a custom group for each role with only the specific permissions they need. Start with the closest template and remove permissions you don't want to grant.
{% endtab %}
{% endtabs %}
#### 2. Create a Group
{% stepper %}
{% step %}
#### Open Group Settings
In the left sidebar, expand **People** and click **Groups**. (The Groups page requires the **View groups** permission, which everyone in **Full Access** has. **Create Group** needs **Manage groups**, and changing a group's permissions or Full Access's members still needs **Manage permissions**. Admins are the members of **Full Access**.)
{% endstep %}
{% step %}
#### Create the Group
Click **Create Group**, then give it a name and description.
{% endstep %}
{% step %}
#### Choose a Template
Select a **permission template** as a starting point, or build from scratch.
{% endstep %}
{% step %}
#### Adjust Permissions
Add or remove individual permissions as needed for this group.
{% endstep %}
{% step %}
#### Add Members
Add individual users or connect synced identity provider groups.
{% endstep %}
{% endstepper %}
#### 3. Choose a Default Group (Optional)
Out of the box, everyone who gets the app is a learner. If you'd rather new people start with some permissions:
1. Pick a group: **Reviewer** or **Operators**, or one of your own you create on **People → Groups** (e.g., from the Viewer template). It has to be a group you add people to by hand, without a membership rule
2. On **Settings → General → Access → Access groups**, choose **Set as default** on its row and confirm. See [The default group](/herd-security-docs/settings/settings/access.md#the-default-group)
To go back to learners, choose **Clear default**. If the default group is deleted, Herd clears the default.
Don't narrow **Full Access** itself: it is how Herd makes admins, and Herd keeps it holding every permission.
***
### Permission Reference
Admins always have all permissions. The tables below apply to everyone else with the app, through their groups.
{% tabs %}
{% tab title="Training" %}
| Permission | What It Allows |
| -------------------- | ---------------------------------------------------------------------------------------- |
| View trainings | See all trainings in your organization |
| Create trainings | Build new trainings (manual or AI-generated) |
| Edit trainings | Modify existing trainings |
| Delete trainings | Remove trainings permanently |
| Assign trainings | Send trainings to employees via Slack or Teams |
| Approve trainings | Review and approve pending trainings before they go live |
| Comment on trainings | Read and post comments, replies and suggested edits on any training, without changing it |
| {% endtab %} | |
{% tab title="Tracks" %}
| Permission | What It Allows |
| ------------- | ------------------------------- |
| View tracks | See all learning tracks |
| Create tracks | Build new multi-training tracks |
| Edit tracks | Modify existing tracks |
| Delete tracks | Remove tracks |
| Assign tracks | Assign tracks to employees |
| {% endtab %} | |
{% tab title="Phishing" %}
| Permission | What It Allows |
| ----------------- | ---------------------------------------------------- |
| View phishing | See phishing campaigns and results |
| Manage templates | Create, edit, and delete phishing email templates |
| Approve templates | Review and approve phishing templates |
| Manage campaigns | Create, launch, pause, and delete phishing campaigns |
| {% endtab %} | |
{% tab title="Smishing" %}
| Permission | What It Allows |
| ----------------- | ---------------------------------------------------------------------------- |
| View smishing | See SMS simulation campaigns, templates, and results (`smishing.view`) |
| Manage templates | Create, edit, and delete SMS templates (`smishing.template.manage`) |
| Approve templates | Review and approve SMS templates (`smishing.template.approve`) |
| Manage campaigns | Create, launch, pause, and delete SMS campaigns (`smishing.campaign.manage`) |
SMS simulation pages are gated by these smishing permissions alone: a person does not also need **View phishing** to reach them. The **Simulations** entry in the sidebar appears for anyone holding a view permission for at least one simulation channel and opens on the first channel they can see, and the channel switcher at the top of the Simulations pages only lists the channels that person may view.
{% endtab %}
{% tab title="WhatsApp" %}
| Permission | What It Allows |
| ----------------- | ---------------------------------------------------- |
| View WhatsApp | See WhatsApp simulation campaigns and results |
| Manage templates | Create, edit, and delete WhatsApp templates |
| Approve templates | Review and approve WhatsApp templates |
| Manage campaigns | Create, launch, pause, and delete WhatsApp campaigns |
| {% endtab %} | |
{% tab title="Vishing (Voice)" %}
| Permission | What It Allows |
| -------------------- | ---------------------------------------------------------------------------- |
| Approve attack types | Review and approve new voice attack types (**Vishing > Template > Approve**) |
The Voice channel is enabled per organization by Herd. Its approve permission works exactly like the other channels': admins always hold it, others hold it through a group that's been granted it, and the **Reviews** tab under **Voice** only appears for people who hold it. See [Voice Attack Types](/herd-security-docs/simulations/voice-simulations/attack-types.md#approving-new-attack-types).
{% endtab %}
{% tab title="Compliance & Policy" %}
| Permission | What It Allows |
| ----------------- | ------------------------------------------ |
| View compliance | See compliance campaigns and status |
| Manage compliance | Create, edit, and run compliance campaigns |
| View policies | See all policies |
| Manage policies | Create, edit, delete, and publish policies |
| {% endtab %} | |
{% tab title="Reporting" %}
| Permission | What It Allows |
| ---------------- | ----------------------------------------------------------------------- |
| View dashboard | Access the Dashboard and Reports hub (`reporting.dashboard`) |
| View risk scores | See individual employee risk scores (`reporting.risk_scores`) |
| Configure risk | Tune risk scoring — the risk-appetite weights (`reporting.risk_config`) |
| {% endtab %} | |
{% tab title="Gamification" %}
| Permission | What It Allows |
| ------------------- | --------------------------------------------------------- |
| Manage gamification | Configure leaderboards and points (`gamification.manage`) |
| {% endtab %} | |
{% tab title="AI Insights" %}
| Permission | What It Allows |
| -------------------- | ------------------------------------------------------------------------------------- |
| View AI governance | Access the AI Insights section and view conversation scores (`ai_governance.view`) |
| Manage AI governance | Configure AI Insights settings, connections, and remediation (`ai_governance.manage`) |
These permissions gate the **AI Insights** section. AI Insights is currently in beta and enabled per organization.
{% endtab %}
{% tab title="GitHub Integration" %}
| Permission | What It Allows |
| ------------------------- | -------------------------------------------------------------- |
| View GitHub integration | View GitHub integration data (`github_integration.view`) |
| Manage GitHub integration | Configure the GitHub integration (`github_integration.manage`) |
The GitHub integration is in **beta**.
{% endtab %}
{% tab title="Herd AI" %}
| Permission | What It Allows |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Use Herd AI | Chat with [HerdAI](/herd-security-docs/herdai/herdai.md) in the web app (`herd_ai.use`). The Slack and Teams assistant isn't affected. Learners don't have it. Full Access, Operators and Reviewer include it, and your groups that already granted a permission were given it on October 29, 2026; of the permission templates only **Full Access** includes it, so tick it on any other new group that should use HerdAI |
| {% endtab %} | |
{% tab title="Users & Groups" %}
| Permission | What It Allows |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| View users | See the user list and profiles |
| Manage users | Add, edit, and deactivate users |
| View groups | See group configurations |
| Manage groups | Create, edit, and delete groups and their permissions. You can only edit the name, description or members of a group that grants nothing you don't hold yourself; for any other group (for an Operators member, Full Access) those fields are locked |
| {% endtab %} | |
{% tab title="Organization" %}
| Permission | What It Allows |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Organization settings | Modify organization-level settings (name, branding, SMS) — needed for most Settings pages (`org.settings`). The Settings sidebar entry and the **General** page also open for **Integrations** or **Manage permissions**, showing only the cards those allow |
| Integrations | Configure Slack, Teams, Okta, Azure AD, SCIM tokens, and other integrations (`org.integrations`). Changing who the Teams app installs for additionally needs **View groups** |
| Manage permissions | Manage groups' permissions and the admin list, and set up or disable [single sign-on](/herd-security-docs/okta/okta-single-sign-on.md) — holding this makes someone an admin, since they can grant any permission (`org.permissions`). **Full Access** includes it; give it to other groups only if their members should be admins |
| {% endtab %} | |
| {% endtabs %} | |
***
### Who Can Approve Simulation Templates
Every simulation channel — email, SMS, WhatsApp, and voice — reviews new content the same way. Whether review is **required** is a setting in the [Simulation settings drawer](/herd-security-docs/simulations/phishing-simulations/navigating-phishing-simulations-page.md#simulation-settings). **Who may approve** is a permission, one per channel:
| Channel | Approve permission |
| --------------- | --------------------------------- |
| Email phishing | **Phishing > Template > Approve** |
| SMS (smishing) | **Smishing > Template > Approve** |
| WhatsApp | **Whatsapp > Template > Approve** |
| Voice (vishing) | **Vishing > Template > Approve** |
* **Admins** always have all four — there's nothing to configure.
* **Everyone else** gets them through group membership: grant the permission to a group in **People › Groups**, and everyone in that group can approve on that channel.
* **Members** can't approve.
The **Reviews** tab for a channel only appears for people who can approve on it, so people without the permission never see a queue they can't action.
{% hint style="info" %}
There is **no approver picker** in the simulation settings drawer. If you used to nominate "Admins only" or a specific group there, that control is gone — use the channel's approve permission and your groups instead.
{% endhint %}
***
### Permission Templates
Templates are pre-built permission sets that make group setup faster. Use them as a starting point — you can add or remove individual permissions after applying one.
| Template | Best For | Includes |
| ---------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| **Training Manager** | HR teams, L\&D coordinators | View, create, edit, delete, assign, and comment on trainings |
| **Training Reviewer** | Managers who approve content | View and approve trainings |
| **Security Manager** | Security team leads | Full training, phishing, smishing, tracks, reporting, and gamification access |
| **Compliance Manager** | Compliance officers, GRC teams | Compliance campaigns, policies, and dashboard access |
| **Viewer** | Leadership, auditors | Read-only access to all content, dashboards, users, and groups (also includes AI Insights view and GitHub integration view) |
| **Full Access** | Admins | Every permission, including **Manage admins and permissions**, so everyone in a group built from it is an admin |
{% hint style="info" %}
The default **Full Access** group holds every permission in your organization, including **Manage admins and permissions** (`org.permissions`, which lets a holder grant any permission and set up [single sign-on](/herd-security-docs/okta/okta-single-sign-on.md)), **Manage network access** (`org.network`) and **Send announcements** (`comms.announce`). Everyone in it is an admin, so give it only to people who should be admins. People join it when they get the app (an admin's invite or grant, your identity provider's Herd app role, or any sign-in) while it is your default group, and when an admin adds them to it on **People → Groups**. A [SCIM](/herd-security-docs/settings/settings/scim-provisioning.md) token can never grant **Manage admins and permissions**, **Manage network access** or **Send announcements**, so a SCIM group push can't add anyone to Full Access or remove anyone from it. An organization must always keep at least one admin.
{% endhint %}
***
### What Happens Without a Permission
Navigation follows your permissions: sidebar entries and in-page links to pages you can't access are hidden or rendered as plain text, and opening such a page directly redirects you to the first page you *can* see. Two useful exceptions:
* **Managers always see their own direct reports' results.** A manager (by the directory `manager` relationship) can view their reports' training and phishing results — on the Dashboard's **Team Report** widget and by asking [HerdAI](/herd-security-docs/herdai/herdai.md) — with no permission grants needed. This never extends to anyone else's team.
* **Members see their own data.** Everyone can ask the Herd bot about their own trainings and phishing results.
***
### Ownership Scoping
When people who aren't admins create trainings, campaigns, or other content, that content is owned by their group.
* They can only **edit and delete** content owned by groups they belong to. For simulation campaigns (email, SMS, WhatsApp and voice) this also covers **launching, pausing and resuming**, including when asked through HerdAI
* Copies follow the same rule: a duplicated, re-sent or re-smished campaign, a campaign HerdAI creates, and one created from an approved agentic cohort is owned by the creator's group (an Admin's is unowned)
* They can **view** content from other groups if they have the relevant view permission
* **Admins** can see and manage all content regardless of ownership
This prevents department heads from accidentally modifying each other's work while still allowing visibility across the organization.
***
### Common Questions
Can someone give themselves more permissions?
No. Only users with the **Manage Groups** permission can change group permissions, and they can only modify groups — not grant themselves Admin access. Only an admin (someone holding **Manage admins and permissions**) can make someone an admin.
What happens when I remove someone from a group?
They immediately lose that group's permissions. If they belong to other groups, they keep those permissions. They keep the app: if they're left in no group with permissions, they're a learner. To take the app away, use **Remove app access** on their page.
Can I sync groups with my identity provider?
Yes. Groups can pull members from **Okta**, **Azure AD** and **Google Workspace** (Slack user groups are retired). The rule builder only offers attributes and groups from directories you've connected. When someone is added or removed in your IdP, their Herd permissions update automatically.
What's the difference between an Admin and someone in Full Access?
There isn't one: everyone in Full Access holds **Manage admins and permissions**, so they are an admin. They stop being an admin when they leave the group, and keep the app.
How do I give new people some permissions automatically?
Set a default group: on **Settings → General → Access → Access groups**, choose **Set as default** on **Reviewer**, **Operators**, or a restrictive group of your own; see [The default group](/herd-security-docs/settings/settings/access.md#the-default-group). Everyone who gets the app from then on joins it. Leave the default empty to keep new people as learners. Don't narrow **Full Access** itself: it is your admins' group, and Herd keeps it holding every permission.
I accidentally locked myself out. What do I do?
Ask another Admin in your organization to restore your group membership. If no other Admins are available, contact Herd support.
***
### Best Practices
{% hint style="success" %}
1. **Set up groups early** — Don't leave the default Full Access group unchanged. Configure proper groups before inviting your team.
2. **Use least privilege** — Start with the minimum permissions needed and add more as required.
3. **Mirror your org structure** — Use IdP group sync so permissions stay up to date automatically.
4. **Review permissions quarterly** — As roles change, make sure group memberships still reflect current responsibilities.
5. **Keep at least two Admins** — So you're never locked out if one Admin leaves the organization.
6. **Use templates as starting points** — They cover the most common use cases and save setup time.
{% endhint %}