> For the complete documentation index, see [llms.txt](https://docs.bluestorm.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bluestorm.io/overview/user-roles-and-access.md).

# User Roles & Access

AppControl uses two access layers:

1. **User role** decides which product areas a user can use.
2. **App role** decides what a user can do in each app they can see.

Most users need both.

* A user role without app access means the user can sign in, but may see no apps.
* App access without the right user role means the user can see an app, but some actions stay unavailable.
* **Platform Administrator** is the exception. This role already has full visibility.

{% hint style="info" %}
Rule of thumb:

* **User role** = feature access
* **App role** = app-level actions
* **App Groups** = delegation (policy / release / task management) and visibility
* **User Groups** = app role assignment at scale
  {% endhint %}

### Access model at a glance

{% code title="How AppControl decides access" overflow="wrap" %}

```
User signs in
   ↓
User role unlocks product areas
   ↓
App access makes apps visible
   ↓
App role unlocks actions in each visible app
```

{% endcode %}

{% code title="Ways a user gets app access" overflow="wrap" %}

```
Platform Administrator
   └─ sees all apps

Other users
   ├─ Direct app access
   │    └─ one user → one app
   ├─ App group membership
   │    └─ one user → all apps in one app group → App Member
   └─ User group membership
        └─ many users → many apps → configurable app role
```

{% endcode %}

### Choose the right access path

{% columns %}
{% column %}

#### App groups

Use app groups to delegate management.

* One app belongs to one app group.
* Group members get **App Member** on all apps in that group.
* Group administrators manage group members and group resources.

See [App Groups](/administration/app-groups.md).
{% endcolumn %}

{% column %}

#### User groups

Use user groups to grant app roles to many users.

* One user group can contain many apps.
* Members inherit access on every app in the group.
* Each member can be **App Owner**, **App Administrator**, **App Member**, or **App Operator**.

See [User Groups](/administration/user-groups.md).
{% endcolumn %}
{% endcolumns %}

#### Direct app access

Use direct app access for one-off cases.

This is useful when a user needs access to one app only.

### User roles

User roles control which product areas a user can use.

<table><thead><tr><th width="170">Role</th><th>Use this for</th><th>Access</th></tr></thead><tbody><tr><td><strong>Platform Administrator</strong></td><td>Central platform management</td><td>Manage system settings, groups, access, all policies, all pipelines, and all tasks. View all apps and repository data.</td></tr><tr><td><strong>Group Administrator</strong></td><td>Delegated management for one or more app groups</td><td>Manage group members, user access, group policies, group pipelines, and group tasks for assigned groups.</td></tr><tr><td><strong>App Administrator</strong></td><td>App-level operations</td><td>Manage app policies, app pipelines, and app tasks for apps the user can access.</td></tr><tr><td><strong>App Viewer</strong></td><td>Read-only access</td><td>View visible apps and their related dashboards and data.</td></tr><tr><td><strong>Policy Viewer</strong></td><td>Policy and insight review</td><td>View policy and insight data for visible apps. Policy changes still require the right app role.</td></tr><tr><td><strong>No Access</strong></td><td>Disabled or inactive users</td><td>No access to AppControl.</td></tr></tbody></table>

{% hint style="warning" %}
**App Administrator** exists in two places:

* as a **user role**, it unlocks app management features
* as an **app role**, it grants admin rights on a specific app

A user needs both to fully manage an app. Note that if you add a user as an App Administrator to an app, that the App Administrator user role will automatically be granted to them.
{% endhint %}

### App roles

App roles apply per app.

<table><thead><tr><th width="170">Role</th><th>Use this for</th><th>Access</th></tr></thead><tbody><tr><td><strong>App Owner</strong></td><td>Business or service ownership</td><td>Manage app info and approve releases. View policy, release, task, environment, and repository information.</td></tr><tr><td><strong>App Administrator</strong></td><td>Operational ownership</td><td>Manage app policies, app pipelines, app tasks, create releases, and approve releases. View policy, release, revision, environment, configuration, task, and repository information.</td></tr><tr><td><strong>App Member</strong></td><td>General team access</td><td>View policy, release, environment, task, and repository information.</td></tr><tr><td><strong>App Operator</strong></td><td>Release execution</td><td>Create releases. This can be limited to specific environment types.</td></tr></tbody></table>

{% hint style="info" %}
Users with the **Policy Viewer** user role only get policy access for apps where they also have app visibility.
{% endhint %}

### Common combinations

These combinations cover most setups:

* **Platform Administrator** — full platform access and full app visibility.
* **Group Administrator** + assigned app group — delegated management for one domain or team.
* **App Viewer** + app group membership — read-only access to every app in that group.
* **App Administrator** user role + **App Administrator** app role — full app-level operations for a specific app.
* **Policy Viewer** + **App Member** — review policy results and insights without release or task management.

### Common scenarios

#### Give a team read-only visibility for a set of apps

Add the users as members of an app group.

Give them the **App Viewer** user role.

#### Give an operations team release rights across many apps

Create a user group with those apps.

Add the users to the user group with the **App Operator** app role.

#### Delegate management for one app domain

Create an app group.

Assign a **Group Administrator** to that group.

Use user groups when the team also needs app roles across the apps in that group.

### Troubleshooting access issues

#### The user can sign in, but sees no apps

Check whether the user has app access through one of these paths:

* direct app access
* app group membership
* user group membership

#### The user can see an app, but cannot perform an action

Check both layers:

* does the user role allow the product area?
* does the app role allow the action on that app?

#### The user was added to an app group, but still lacks release or admin rights

App group membership only grants **App Member**.

Use a user group or direct app access when the user needs **App Owner**, **App Administrator**, or **App Operator**.

### See also

* [Getting Started](/overview/getting-started.md)
* [Platform Administrator](/overview/getting-started/platform-administrator.md)
* [Group Administrator](/overview/getting-started/group-administrator.md)
* [App Groups](/administration/app-groups.md)
* [User Groups](/administration/user-groups.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bluestorm.io/overview/user-roles-and-access.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.