Epsilon3 uses a Role Based Permissions model to determine what users can see and do within a workspace and its projects. This model enhances the current permissions structure with a more robust and flexible approach.

Under Role Based Permissions, all access is granted through roles. Users do not receive permissions directly. Instead, one or more roles are assigned to a user, and each role explicitly defines the permissions that role provides.

Because roles directly control operational capability, correct configuration is critical.

Permissions in Epsilon3 are built on three foundational principles:

Understanding these principles is essential before configuring roles.

A role is a reusable collection of permissions. Roles are defined once and can be assigned to any number of users.

Each role may include permissions from any of the following categories:

These categories are purely organizational. Higher categories do not include or inherit lower categories.

For example, a role with Edit permissions does not automatically allow viewing the edited content. View permissions must be explicitly granted through the same role or an additional role.

Roles are created from Settings > Roles.

When creating a role, you define:

Roles are fully customizable. There is no fixed limit to the number of roles in a workspace.

Within each permission category, you may either select all permissions in that category or enable individual permissions selectively. Selecting all permissions in a category does not affect any other category.

Once created, roles can be edited at any time. Changes take effect immediately for all users assigned that role.

Roles can be modified at any time from Settings > Roles by selecting the role code.

Any change to a role immediately affects all users assigned that role, regardless of whether the role is applied at the workspace or project level.

For this reason, roles should be treated as shared infrastructure rather than user-specific configuration.

Users can be assigned multiple roles simultaneously.

When multiple roles are assigned, the user receives the union of all permissions granted by those roles.

There is no precedence or conflict resolution between roles. If ANY role grants a permission, the user has that permission.

This role based permissions model does not support permission denial. Permissions can only be granted or omitted.

Workspace roles define what a user can do across the workspace by default.

Workspace roles are assigned from Settings > Users and apply to projects only when the user is added to the project and no project-level roles are explicitly assigned.

When one or more roles are assigned at the project level, workspace roles are not evaluated for that project.

Workspace roles are assigned from Settings > Users. From this page, administrators can select one or more users and apply one or more roles. Multiple roles may be assigned to the same user, and the permissions granted by those roles are combined.

Select one or more users on the left, click Edit Workspace Roles, and use the drop down menu to apply one or more roles to the selected users.

Workspace role assignments take effect immediately. Changes to assigned roles update the user’s effective permissions as soon as they are saved.

Because roles are reusable and additive, workspace access is typically granted by assigning a small number of well-defined roles rather than creating user-specific configurations.

Project roles define what a user can do within a specific project or subproject.

A user must be explicitly added to a project to have any project-level access.

Project roles can be assigned in two places:

From the Users page:

From the Project page (Settings > Projects > Specific project) users can be added to projects by clicking into the Users tab and selecting + Add User.

Select one or more users and either Remove from the project or Edit the role assignments.

Groups allow you to manage workspace and project permissions in bulk. Instead of assigning roles to users individually, you can create a Group, assign one or more roles to that Group, and then control access simply by adding or removing users from the Group.

Groups are especially helpful when:

Groups work within the Role-Based Permissions model. Any roles assigned to a Group apply to all members of that Group.

A Group includes:

When a user is added to a Group, they automatically inherit:

If a user is removed from the Group, those permissions are removed accordingly.

Once created, the Group will appear in the Groups list.

To modify a Group:

Changes take effect immediately for all members of the Group.

To manage membership:

This immediately updates the user’s inherited permissions.

Groups are a scalable way to manage permissions in Epsilon3. By assigning roles to Groups and managing access through membership, teams can maintain consistent access control, simplify onboarding, and reduce administrative complexity.

Groups fully support and extend the Role-Based Permissions model, enabling permission management at both the workspace and project levels.

The Role Based Permissions model is an upgrade to the existing permissions system and introduces greater flexibility in how permissions are defined and applied. While this update includes changes to how permissions are configured and displayed in the user interface, it does not impact existing access or permission behavior at rollout. No preparation is required in advance, and current settings will continue to function as expected unless administrators choose to update or refine role assignments.