Overview
Ekso has two layers of access control:
- Application-level — controls who can access major areas of the application (boards, insights, finance, etc.)
- 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.
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 |
Field-level roles are configured per process within each container, not at the application level. See field-level access control for details.
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.
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.
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:
- Application-level determines whether a user can access the area at all (e.g., can they see boards?)
- Container-level determines what they can do within a specific container (e.g., can they add items to this container?)
- 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