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

# Access control

> Manage permissions across your tenant with application-level access control areas, roles, and user groups.

## Overview

Ekso has two layers of access control:

1. **Application-level** — controls who can access major areas of the application (boards, insights, finance, etc.)
2. **Container and process-level** — controls who can interact with specific containers, items, and fields

This page covers application-level access control. For container and process-level permissions, see [Containers](/guide/concepts/containers#access-control).

You manage application-level access control under **Settings > Access Control**.

## Access control areas

Access control is organized into six areas, each representing a major section of the application:

| Area      | What it controls                                                                                |
| --------- | ----------------------------------------------------------------------------------------------- |
| Container | Access to containers and the items within them                                                  |
| Board     | Access to boards, cycles, and planning features                                                 |
| Insights  | Access to reports and analytics dashboards                                                      |
| Finance   | Access to financial configuration — job roles, cost centers, SKUs, CRM, and budget reason codes |
| Docs      | Access to the documentation module                                                              |
| Timesheet | Access to timesheet views and time entry management                                             |

Each area has its own set of role assignments. This means you can grant a user group full access to boards while restricting their access to finance settings.

## Roles

Roles define what a user group can do within an access control area. The available roles are:

### Standard roles

| Role       | Permission                                |
| ---------- | ----------------------------------------- |
| View       | Can view content in the area              |
| Add        | Can create new content in the area        |
| Change     | Can modify any content in the area        |
| Change Own | Can modify only content they created      |
| Delete     | Can remove any content in the area        |
| Delete Own | Can remove only content they created      |
| Filter     | Can filter and search content in the area |
| Manage     | Full administrative control over the area |

### Area-specific roles

| Role | Applies to | Permission                            |
| ---- | ---------- | ------------------------------------- |
| Plan | Board      | Can assign items to boards and cycles |

### Field-level roles

These roles apply to process field access within containers:

| Role         | Permission                                     |
| ------------ | ---------------------------------------------- |
| Field View   | Can see the field value                        |
| Field Add    | Can set the field value when creating an item  |
| Field Update | Can change the field value on an existing item |

<Note>
  Field-level roles are configured per process within each container, not at the application level. See [field-level access control](/guide/concepts/processes#field-level-access-control) for details.
</Note>

## User groups

Access control assignments are made to **user groups**, not individual users. Ekso creates two built-in groups during tenant setup:

| Group    | Description                                                        |
| -------- | ------------------------------------------------------------------ |
| Everyone | Automatically includes all users in the tenant. Cannot be deleted. |
| Nobody   | An empty group. Use it to explicitly deny access to an area.       |

You can create additional custom groups to represent teams, departments, or permission tiers — for example, "Developers", "Support", "Team Leads", or "Finance Admins."

### How groups work

* A user can belong to multiple groups
* Permissions are additive — if any of a user's groups grants a role, the user has that permission
* There is no explicit "deny" — remove the group assignment to revoke access

## Default permissions

When a new tenant is created, Ekso grants the **Everyone** group the following roles across all six areas:

| Role   | Granted by default |
| ------ | ------------------ |
| View   | Yes                |
| Add    | Yes                |
| Manage | Yes                |

This gives all users basic access to every area out of the box. Admins can then tighten permissions by reassigning roles to more specific groups.

<Tip>
  Start with the defaults and restrict as needed. It is easier to remove permissions from a broad grant than to troubleshoot why users cannot access features.
</Tip>

## System rules

Some access control rules are marked as **system** rules. These are essential for the application to function and cannot be deleted. You can change which user groups are assigned to system rules, but you cannot remove the rules themselves.

## How it all fits together

Application-level access control works alongside container and process-level permissions:

1. **Application-level** determines whether a user can access the area at all (e.g., can they see boards?)
2. **Container-level** determines what they can do within a specific container (e.g., can they add items to this container?)
3. **Process field-level** determines which fields they can see, set, and change on items of a specific type

A user needs permissions at all three levels to interact with an item. For example, to change a field on an item:

* They need **Board > View** (application level) to see the board
* They need **Change** on the container (container level) to edit items
* They need **Field Update** on the specific field (process level) to modify that field value