User access model

Overview

Envtracker is organized so you can control who can see and change things per project, without giving everyone tenant-wide permissions.

In most cases:

• Admins already have full access and do not need project assignment
• Everyone else gets access through project roles and, for some roles, workspace assignments

How your data is organized

Envtracker groups your work like this:

• A tenant contains one or more projects
• Each project contains workspaces
• Workspaces contain environments
• Each environment can contain multiple applications

If a user can access something higher in the list, they can access what is inside it.

Project roles

Project access is managed by assigning users a project role.

Manager

Managers have full access within the project.

Limit:

• A manager cannot assign or promote other users to the manager role

Analyst

Analysts can view and use project-wide features such as analytics and can access all workspaces in the project.

Limit:

• Analysts cannot access project settings

Member

Members can perform day-to-day actions in environments they have access to, such as editing applications and deploying.

Important:

• Members must be assigned to specific workspaces to gain access to the environments inside them

Viewer

Viewers have read-only access to environments they have access to.

Important:

• Viewers must be assigned to specific workspaces to gain access to the environments inside them

Workspace assignment

Workspace assignment is how you control which environments a member or viewer can access.

• If a member or viewer is not assigned to a workspace, they will not see or access its environments
• Managers and analysts are not limited by workspace assignment

Shared workspaces

A shared workspace is a workspace that all members and viewers can access automatically, without explicit assignment.

Use shared workspaces for environments that should be visible to everyone in the project, such as common sandboxes or shared staging environments.

Access scopes

Access scopes let you control which actions are allowed in environments for members and viewers.

Each scope maintains a list of actions it controls. For example, actions commonly include:

• Deploy
• Delete an application
• Update an application
• Configure an application
• Change application ordering

The exact list of actions can change over time as Envtracker adds features.

In the tenant UI, these actions are shown in a human-friendly way, for example “Permit app delete” or “Deny deploy” rather than internal action codes.

How scopes are applied

Scopes are attached to both:

• Environments (to define what rules apply in that environment)
• Users (to define what rules apply to that user)

On access checks, Envtracker evaluates the user scopes and the environment scopes together.

Permit scopes vs deny scopes

• Members can only be assigned to deny scopes
• Viewers can only be assigned to permit scopes

This keeps the default behavior simple:

• Members generally have action access, with specific actions denied when needed
• Viewers are read-only by default, with explicit permissions granted when needed

Managers and analysts are not managed with access scopes.

Pages available to everyone in a project

Some project pages are available to all project users regardless of role:

• Stories
• Releases
• AI insights