> ## Documentation Index
> Fetch the complete documentation index at: https://docs.condense.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Roles and Permissions
## Overview
Condense provides a layered Role-Based Access Control (RBAC) system that defines how users are onboarded, granted access, and permitted to operate within the platform. This RBAC model supports:
* Clear administrative separation
* Strong isolation between environments and workspaces
* Predictable and least-privilege access assignment
* Smooth governance for teams of all sizes
The RBAC model spans two areas of the Condense platform:
**Condense Console** – the organization control plane **Condense Core** – the operational data plane containing environments and workspaces
This document describes each role, how access propagates, and how administrators assign members across these layers.
## Multi-Organization Access (New in v2.4.1)
Starting with **Condense v2.4.1**, users can belong to multiple organizations using a single Condense account.
Each organization maintains its own:
* Members
* Roles
* Environments
* Workspaces
* Permissions
When a user switches organizations, Condense evaluates access using the roles assigned within the currently active organization.
Roles and permissions are isolated between organizations. Membership in one organization does not grant access to resources in another organization.
## **Access Layers in Condense**
Condense access is structured into three layers:
Copy
```text theme={null}
Organization → Environment → Workspace
```
Each layer has its own hierarchy, responsibilities, and roles. The diagram below shows the complete flow of access across Organization, Environment, and Workspace layers in Condense
## **Organization Layer** *(Condense Console)*
The Organization layer controls the company’s identity within Condense. Here, administrators manage:
* Organization profile
* Users and roles
* Environment onboarding
* Member invitation
* Billing visibility
> Organization roles control **who governs the organization**, and **who can grant access to specific environments**.
### **Organization Roles**
#### **Organization Admin**
The top-level administrative role for the entire organization.
**Responsibilities**
* Set up and manage the organization
* Invite new members
* Assign Organization-level roles (Billing Admin, Account Admin, Environment Admin, Environment User)
* Assign environment access to members
* Link and manage environments associated with the organization
**Access Flow**
While Organization Admin manages access centrally, they must assign themselves an Environment Admin or Environment User role to operationally enter a specific environment.
#### **Account Admin**
Focused on access management for assigned environments.
**Responsibilities**
* Invite members to their assigned environments
* Assign environment roles (Environment Admin or Environment User)
* Suspend users in the environments they manage
#### **Billing Admin**
Role for financial governance and usage management.
**Responsibilities**
* View billing details and usage reports
* Manage payment information
* Visibility limited to the environments assigned to them
#### **Environment Admin (assigned from Console)**
An Organization Admin can assign a member to become Environment Admin for one or more environments.
This grants full access in those environments within Condense Core.
#### **Environment User (assigned from Console)**
A non-admin member of an environment.
Environment Users gain workspace-level access only through workspace-role assignments inside Condense Core.
## **Environment Layer** *(Condense Core)*
An Environment represents an isolated execution space containing Workspaces, applications, connectors, Kafka resources, and monitoring.
Each user entering an environment receives one of two roles:
* Environment Admin
* Environment User
These roles control access to Workspaces and operational features.
### **Environment Admin**
The highest authority within an environment.
**Capabilities**
* Full visibility into every workspace in the environment
* Create and manage workspaces
* Manage workspace membership
* Configure pipelines, connectors, transforms, and utilities
* Create, modify, and delete applications
* Access Kafka operations (topics, consumer groups, schema registry)
* View environment metrics and dashboards
Environment Admins do **not** need workspace-role assignments. They can operate across all workspaces automatically.
### **Environment User**
A non-administrative user who has access to the environment but **does not automatically see any workspace**.
Workspace visibility and workflow access depend entirely on the workspace roles assigned to them.
#### **Single-role assignment model**
Within an environment:
* An Environment User receives **one workspace role** (e.g., Developer, Maintainer)
* The role applies to **all workspaces selected** during assignment
* If more workspaces are added later, they must receive **the same role**
* Environment Users **cannot** hold mixed roles (e.g., Developer in W1 and Viewer in W2) within the same environment
> This simplifies governance and preserves consistent privilege levels.
## **Workspace Layer** *(Condense Core)*
Workspaces are operational areas inside an environment, each hosting its own applications, connectors, pipelines, and Kafka-based resources.
Workspace roles determine operational capability.
### **Workspace Roles**
#### **Kafka Admin**
Full Kafka management inside the assigned workspace(s). Manages topics, consumer groups, schema registry entities, and compatibilities.
#### **Maintainer**
Responsible for deploying and managing connectors, transforms, and utilities.
#### **Developer**
Creates, updates, and publishes applications. Can restore and delete applications in the assigned workspaces.
#### **Viewer**
Read-only access to applications, connectors, logs, and configurations.
## **How Access Works Together**
### **Access to Condense Core**
To enter an environment inside Condense Core, a user must have:
* Environment Admin, or
* Environment User
assigned at the organization layer.
Environment Admin → full environment visibility
Environment User → workspace visibility only after workspace-role assignment
### **Workspace Access**
Environment Admin
→ Sees and manages all workspaces automatically
Environment User
→ Sees only the workspaces for which a workspace role was assigned
→ Workspace role must be the same across all selected workspaces
## **Member & Role Assignment Flow**
### **Creating an Organization and Becoming Organization Admin**
1. Sign up or create a new organization in Condense Console [https://console.condense.zeliot.in/signUp](https://console.condense.zeliot.in/signUp)
2. The creator automatically becomes the **Organization Admin**
3. Environment(s) can now be linked to the organization
### **Inviting Members**
As Organization Admin:
1. Go to **Members**
2. Select **Invite Member**
3. Enter user details
4. Send invite
Once accepted, the member appears under the organization.
5. Select the member and assign one of the Organization-level roles:
* Organization Admin
* Account Admin
* Billing Admin
* Environment Admin (for selected environments)
* Environment User (for selected environments)
You cannot assign any role to member if there is no Environment is associated to organization
### **Assigning Organizational Roles**
Organization Admins can assign:
* Organization Admin
* Account Admin
* Billing Admin
These roles control access in Condense Console.
### **Assigning Environment Roles**
Organization Admin or Account Admin can:
1. Select a member
2. Choose **Add to Environment**
3. Select an environment
4. Assign either:
* Environment Admin
* Environment User
This determines the member’s access level inside Corrdese Core.
### **Assigning Workspace Roles (inside Condense Core)**
Only **Environment Admins** do this.
For an Environment User:
1. Navigate to **Members** in Condense Core
2. Select the Environment User
3. Choose **Assign Workspace Role**
4. Select role:
* Kafka Admin
* Maintainer
* Developer
* Viewer
5. Select one or more workspaces
> **Note** The role selected applies to all selected workspaces. Later additions must use the same role.
## **Example Scenario**
#### **Setup**
**Environments**: Production, Testing
**Workspaces**: FleetTracking, ColdChain, Sandbox
| Name | Org Role | Environment Role | Workspace Role |
| ------ | ------------------ | ---------------------- | ------------------------------------ |
| Anita | Organization Admin | Env Admin (Prod, Test) | — |
| Bharat | Account Admin | Env User (Prod) | Kafka Admin — FleetTracking |
| Divya | — | Env Admin (Test) | Maintainer — Sandbox |
| Eshan | — | Env User (Prod) | Developer — FleetTracking, ColdChain |
| Farah | — | Env User (Test) | Viewer — Sandbox |
#### **User Experience**
* **Anita** Full authority across both environments and all workspaces.
* **Bharat** Sees Production only. Sees only FleetTracking because of the Kafka Admin role.
* **Divya** Sees all workspaces in Testing. Can deploy and manage connectors in Sandbox.
* **Eshan** Sees Production. Sees FleetTracking and ColdChain as Developer.
* **Farah** Sees Sandbox with read-only access.
#### **Behavior**
* Environment Admins see and operate across **all workspaces** of their environments
* Environment Users only see the workspaces they have a role for
* Workspace roles for an Environment User always remain uniform across all selected workspaces
## Capability **Overview**
| Capability | Env Admin | Env User (Workspace Role) |
| ------------------------------- | :------------: | :-----------------------: |
| Access all Workspaces | ✅ | ❌ |
| Access only assigned Workspaces | Not applicable | ✅ |
| Create / delete Workspaces | ✅ | ❌ |
| Manage Workspace members | ✅ | ❌ |
| Deploy connectors | ✅ | Maintainer only |
| Develop applications | ✅ | Developer only |
| Kafka operations | ✅ | Kafka Admin only |
| View everything | ✅ | Viewer only |
Condense RBAC provides a structured, predictable access model across three layers:
* **Organization Layer** : governs who administers the organization and who can assign access
* **Environment Layer** : determines seniority and visibility for operations
* **Workspace Layer** : controls fine-grained operational capabilities
Environment Admins manage the entire environment and all workspaces. Environment Users gain workspace access only through explicit workspace-role assignments using a consistent role across selected workspaces.
This model keeps permissions clear, secure, and scalable, supporting diverse teams collaborating across multiple environments and workspaces.
## Lifecycle Guide
The following lifecycle illustrates how users are onboarded and granted access to resources in Condense using the Role-Based Access Control (RBAC) model.
### Step 1: Create an Organization
A user signs up for Condense and creates a new organization. The creator is automatically assigned the **Organization Admin** role.
**Outcome**
* Organization created
* Organization Admin assigned
* Ready to link environments
***
### Step 2: Link an Environment
The Organization Admin links one or more Condense environments to the organization.
**Outcome**
* Environment becomes available within the organization.
* Environment-level roles can now be assigned.
***
### Step 3: Invite Members
The Organization Admin invites users to the organization by sending an invitation to their email address.
Once the invitation is accepted, the member becomes part of the organization.
**Outcome**
* Member added to the organization.
* Ready for role assignment.
***
### Step 4: Assign Organization Roles
Assign the appropriate organization-level role based on the user's responsibilities.
Available roles include:
* Organization Admin
* Account Admin
* Billing Admin
These roles determine administrative access within the Condense Console.
**Outcome**
* Organization-level responsibilities assigned.
***
### Step 5: Assign Environment Roles
Assign the user to one or more linked environments.
Available roles include:
* Environment Admin
* Environment User
These roles determine whether the user can administer or access a specific environment.
**Outcome**
* User gains access to the selected environments.
***
### Step 6: Assign Workspace Roles
For users assigned the **Environment User** role, an Environment Admin grants workspace-level access within Condense Core.
Available workspace roles include:
* Kafka Admin
* Maintainer
* Developer
* Viewer
Workspace roles determine the operations that users can perform within their assigned workspaces.
**Outcome**
* User receives operational access to assigned workspaces.
***
### Step 7: Access Condense Core
After all required roles have been assigned, users can access Condense Core according to their permissions.
Depending on their assigned roles, users can:
* Access workspaces
* Deploy connectors
* Develop applications
* Manage Kafka resources
* Configure pipelines
* Monitor platform resources
***
### Step 8: Ongoing Access Management
As teams evolve, administrators can:
* Invite additional members
* Modify organization roles
* Update environment assignments
* Change workspace roles
* Remove members
* Link additional environments
Starting with **Condense v2.4.1**, users can belong to multiple organizations using the same Condense account. Each organization maintains its own members, environments, workspaces, roles, and permissions independently.
## **Frequently Asked Questions (FAQs)**
### Q1: What is Role-Based Access Control (RBAC) in Condense?
RBAC (Role-Based Access Control) is Condense's permission model that controls what users can view and manage within the platform. Access is granted through three layers: Organization, Environment, and Workspace.
***
### Q2: What are the three access layers in Condense?
Condense organizes permissions into three layers:
* **Organization Layer** – Manages users, organization settings, billing, and environments.
* **Environment Layer** – Controls access to specific Condense environments.
* **Workspace Layer** – Provides fine-grained operational permissions within individual workspaces.
***
### Q3: Who can invite members to an organization?
Only **Organization Admins** can invite new members to an organization and assign organization-level roles.
***
### Q4: What is the difference between Organization Admin and Environment Admin?
An **Organization Admin** manages the organization, members, billing, and environment assignments through the Condense Console.
An **Environment Admin** manages operational resources within assigned environments, including workspaces, connectors, pipelines, applications, and Kafka resources.
***
### Q5: Can an Organization Admin access every environment automatically?
No. Although an Organization Admin manages organization-wide settings, they must also be assigned as an **Environment Admin** or **Environment User** to access resources inside a specific environment.
***
### Q6: What is the difference between Environment Admin and Environment User?
An **Environment Admin** has full access to all workspaces and resources within the assigned environment.
An **Environment User** can access only the workspaces where they have been assigned a workspace role.
***
### Q7: Do Environment Admins require workspace roles?
No. Environment Admins automatically have access to all workspaces within the environments they administer.
***
### Q8: What workspace roles are available?
Condense supports the following workspace roles:
* Kafka Admin
* Maintainer
* Developer
* Viewer
Each role provides a different level of operational access within assigned workspaces.
***
### Q9: Can an Environment User have different workspace roles in the same environment?
No. An Environment User is assigned a single workspace role within an environment. If additional workspaces are assigned later, the same role applies to all selected workspaces.
***
### Q10: Can workspace roles be changed later?
Yes. Environment Admins can update workspace assignments and roles as required.
***
### Q11: Can I assign Environment Roles before linking an environment?
No. Environment roles can only be assigned after at least one environment has been linked to the organization.
***
### Q12: What happens when a member is removed from an organization?
Removing a member revokes access to all environments and workspaces associated with that organization. Access to other organizations, if any, remains unaffected.
***
### Q13: Can a user belong to multiple organizations?
Yes. Starting with **Condense v2.4.1**, a single Condense account can belong to multiple organizations. Users can switch between organizations without creating separate accounts.
***
### Q14: Can I have different roles in different organizations?
Yes. Roles are evaluated independently within each organization. For example, you may be an **Organization Admin** in one organization and an **Environment User** in another.
***
### Q15: Does switching organizations affect my permissions?
Yes. When you switch organizations, Condense loads the members, environments, workspaces, and permissions associated with the selected organization.
***
### Q16: Are resources shared across organizations?
No. Organizations are isolated from one another. Members, environments, workspaces, connectors, pipelines, applications, and permissions remain independent for each organization.
***
### Q17: What is the recommended approach for assigning roles?
Follow the principle of least privilege:
* Assign **Organization Admin** only to users managing the organization.
* Assign **Environment Admin** to users managing environments.
* Assign appropriate workspace roles based on operational responsibilities.
* Regularly review and update role assignments as team responsibilities change.
***
### Q18: Where can I manage user roles?
* **Organization Roles** are managed in the **Condense Console**.
* **Environment Roles** are assigned from the **Condense Console** after linking environments.
* **Workspace Roles** are managed by **Environment Admins** within **Condense Core**.