Teams

fDeploy uses team-based role-based access control (RBAC). Users belong to teams, and each team is granted one or more roles — optionally scoped to a specific project or environment. A user’s effective permissions are the union of roles granted to every team they belong to.

Team management (Configuration → Teams) is only accessible to users with the System Manager or System Administrator role.

System teams

Three built-in teams exist and cannot be renamed or deleted:

• Everyone — every authenticated user is an implicit member. Use it to grant baseline permissions to all users. You cannot manually add or remove members.
• Administrators — intended for users who need full system access.
• Managers — intended for users who manage teams, users, and top-level resources.

Custom teams and membership

Beyond the three system teams, you create as many custom teams as you need — typically one per responsibility area (e.g. Backend, Data Engineering, Release Managers). A team is just a named grouping that holds a list of members and a list of role assignments.

There are two ways users end up as members of a team:

• Manual assignment — an administrator opens the team’s Members tab and adds or removes users directly. This is the only option for local and OIDC accounts, and the default for directory accounts.
• AD group mapping — for domain authentication, you can map an Active Directory security group to an fDeploy team. When a domain user signs in, their AD group memberships are reconciled against the mappings and they are added to (or removed from) the corresponding teams automatically. See authentication settings for where the mappings are configured.

OIDC users do not have an equivalent automatic mapping — they must be added to teams manually after their first sign-in.

Note

Deleting a custom team removes its role assignments and drops all members in one step. Members themselves are not deleted — they simply lose the permissions that team granted.

Available roles

Roles are the actual units of permission — teams don’t grant access directly, role assignments do. Roles fall into three categories:

Project roles

Role	Permissions
Project Viewer	Read-only access to projects
Project Contributor	View + edit variables and deployment steps
Project Lead	Contributor permissions + create releases
Project Deployer	Contributor permissions + deploy releases

Environment roles

Role	Permissions
Environment Viewer	View environments and deployment targets
Environment Manager	View + edit environments and deployment targets

System roles

Role	Permissions
System Manager	Manage teams, users, and top-level resources
System Administrator	Full system access including server configuration

Role hierarchy

Higher-level roles implicitly grant the permissions of lower-level roles in the same category:

• Project Lead and Project Deployer both grant Project Contributor and Project Viewer
• Project Contributor grants Project Viewer
• Environment Manager grants Environment Viewer
• System Administrator grants System Manager

You do not need to assign lower roles alongside higher ones — assigning Project Lead is enough to cover view and edit.

Scoping role assignments

Every role assignment can be scoped to limit where it applies:

• Global (no scope) — applies across all projects and environments
• Project-scoped — applies only to the selected project
• Environment-scoped — applies only to the selected environment

Tip

Prefer scoped assignments. Granting Project Deployer globally lets a team deploy every project; granting it scoped to the two projects they own limits blast radius without adding administrative overhead.

How permissions are resolved

When checking whether a user may perform an action, fDeploy:

1. Collects all role assignments from the Everyone team (applies to every user).
2. Collects all role assignments from every other team the user belongs to.
3. Expands role hierarchies — Project Lead also grants Project Contributor and Project Viewer, and so on.
4. Unions the result. If any team grants the required permission, the user has it. There is no deny.

Note

Permission results are cached. Changes to team membership, role assignments, or AD group mappings may take a few minutes to take effect for already-signed-in users.