> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/2-6-0/access/user-management/access-permissions-for-admin-ui.md).

# Access Control for Admin UI

Every page and operation in the Connectware Admin UI is backed by an HTTP permission. This means you can control exactly which features each user can see and interact with by assigning the appropriate HTTP permissions to their role.

## How It Works

The Admin UI makes HTTP requests to the Connectware REST API on behalf of the logged-in user. Each request is checked against that user's permissions. If the user does not have the required permission for a given endpoint, the corresponding UI element — a page, a button, or a table — is hidden or disabled.

This means that:

* A user with read-only HTTP permissions on `/api/services` can view services but cannot install, enable, or delete them.
* A user with no permissions on `/api/users` does not see the **User** navigation item at all.
* Access is additive — a user with multiple roles sees the union of all their roles' permissions.

## Default Roles

The following built-in roles cover the most common access patterns:

**`connectware-admin`** — full access to all Admin UI pages and operations. Assign this role only to system administrators.

**`minimum-access`** — read-only access to a limited set of Admin UI pages. Users with this role can log in and view basic system information but cannot change anything. This role is a useful starting point for custom roles with limited scope.

For the complete list of pages accessible with `minimum-access`, see:

{% content-ref url="/pages/EncKjK1tJOYcAkFkOXQM" %}
[Admin UI Pages Available to Minimum Access Users](/2-6-0/access/user-management/access-permissions-for-admin-ui/minimum-access-role-pages.md)
{% endcontent-ref %}

## Designing Custom Roles

If the built-in roles do not fit your use case, create a custom role with exactly the permissions your users need. A common pattern is:

1. Start with `minimum-access` as a baseline — copy its permissions into a new role using the **Copy Permissions** field in the **Create Role** dialog.
2. Add the additional HTTP permissions for the features you want to enable.
3. Assign the role to your users.

### Common Patterns

| Role type                    | Suggested permissions                                                          |
| ---------------------------- | ------------------------------------------------------------------------------ |
| Service operator (read-only) | `minimum-access` permissions + read on `/api/services/#`                       |
| Service operator (full)      | `minimum-access` permissions + read/write on `/api/services/#`                 |
| User administrator           | `minimum-access` permissions + read/write on `/api/users/#` and `/api/roles/#` |

{% hint style="info" %}
HTTP permissions use the same wildcard syntax as MQTT permissions. `/api/services/#` grants access to all endpoints under `/api/services/`. For full permission syntax, see [Permissions](/2-6-0/access/user-management/permissions.md). For the exact permission required by each page, see the reference below.
{% endhint %}

## Full Permissions Reference

For a complete mapping of which HTTP permission is required for each Admin UI page and operation, see:

{% content-ref url="/pages/99nj5qc5aveisVxNarVa" %}
[Admin UI Permissions](/2-6-0/access/user-management/access-permissions-for-admin-ui/ui-access.md)
{% endcontent-ref %}


---

# 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.cybus.io/2-6-0/access/user-management/access-permissions-for-admin-ui.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.