This document explains how Role-Based Access Control (RBAC) functions when a user has both account-level and project-level permissions assigned. It specifically outlines how Rocketlane determines which permission set takes precedence in case of conflicts.

Overview

Rocketlane allows assigning permissions at two levels:

• Account level permissions: Apply globally across all projects for a user.

• Project level permissions: Apply only within a specific project where they are explicitly defined.

When both types of permissions exist for a user, Rocketlane’s RBAC system evaluates them line by line (for each action or capability) to determine the effective access level.

The governing rule:

For each permission line item (example delete project, edit project >> invite team members, set visibility, Edit task >> edit assignee, start date, due date etc) the higher permission set takes precedence.

The term "higher permission" in the context of Rocketlane RBAC (Role-Based Access Control) refers to the permission level that grants greater or more extensive access or capabilities when comparing two conflicting permissions for the same action.

Permission Hierarchy Logic

Each permission (e.g., "Can delete project", "Can invite members") is individually evaluated to identify whether the account-level or project-level setting grants a higher level of access.

Example 1: Deleting a Project

• Account level: Jennifer can delete projects.

• Project level: Jennifer cannot delete projects. In this case, since there is a direct conflict:

• Rocketlane identifies “Can delete project” as the permission
  

• The account-level permission is enabled (higher permission).

• The project-level permission is disabled (lower permission).

Result: For the "delete project" action, Jennifer retains the ability to delete the project because Rocketlane uses the higher permission from the account level for this specific action despite the project-level restriction.

Example 2: Editing Project Settings

• Account level: Jennifer cannot edit projects.

• Project level: Jennifer can add partners, can invite team members, and can set visibility.

Here, for all “edit-related” line items:

• The project-level permissions are higher because they explicitly grant access.

• These permissions override the restricted account-level settings for those specific functions.

Result: Jennifer can perform those specific edit actions (like adding partners, inviting members) allowed at the project level because the higher permission at the project

level overrides the restricted account-level role but only for those actions explicitly permitted at the project level.

Conflict Resolution Rule

When permissions differ between account and project levels, Rocketlane RBAC applies the higher permission set per line item:

• If a line item is enabled at the account level and disabled at the project level

→ Account-level permission applies.

• If a line item is disabled at the account level and enabled at the project level

→ Project-level permission applies.

• If both levels have the same status → That status defines the access.

This selective override happens independently for each permission item, allowing project-level permissions to grant finer-grained access even when account-level permissions are more restrictive.

This also ensures that each action is evaluated independently and the user gets the most permissive valid configuration without unnecessarily restricting global access.