Skip to main content

Multi-Tenancy

Multi-tenancy is how Console organizes multiple organizations (like your company and your customers) in a way that keeps everyone's data completely separate and secure.

Why Multi-Tenancy Matters​

When using a platform like Console, you need to ensure that:

  • Your company's data is completely isolated from other companies
  • Each company can manage their own users independently
  • Settings, permissions, and data are kept separate
  • A security issue in one organization doesn't affect others

Console handles all of this automatically for you.

The Organization Hierarchy​

Console organizes your data using a clear structure:

Company (Your Organization)
└── Users (Your organization's members)
    └── Groups → Permissions

Company​

The Company represents your organization in Console. It's the top level of your hierarchy.

Every company has:

  • A unique name (e.g., "Acme Corporation")
  • A slug used for login (e.g., "acme-corp")
  • Organization-wide settings
  • Complete data isolation from other companies
Company Slug

Your company slug is what users enter when logging in. It's part of your organization's identity in Console.

User​

Users are the people in your organization. Each user:

  • Has a unique email address (within their company)
  • Belongs to one or more groups (which define permissions)
  • Has a status: invited, active, or inactive

User Lifecycle:

  1. Invited - User has been sent an invitation email
  2. Active - User has set their password and can log in
  3. Inactive - User's access has been temporarily disabled

Groups​

Groups are the primary way to organize users and control permissions within your company. Use them to:

  • Define roles (Administrators, Developers, Viewers)
  • Organize by department (Engineering, Marketing, Sales)
  • Create access levels (Read-only, Editor, Manager)
  • Manage permissions at scale

Groups contain permissions that define what users can do in the system.

Data Isolation​

One of Console's most important features is complete data isolation between companies.

How It Works​

When you log in to Console:

  1. You authenticate with your company slug
  2. Console identifies which company you belong to
  3. All data you see is automatically filtered to your company
  4. You cannot access data from other companies, even if you know their IDs

This means:

  • Each company sees only their own users
  • Permissions are scoped to your company
  • Complete privacy and security

What You See​

When you view...You see only...
UsersUsers in your company
GroupsGroups in your company
PermissionsPermissions in your company
SettingsYour company's settings

Practical Example​

Let's see how this works in practice:

Scenario​

Company: Acme Corp

  • Administrators Group: Alice (Manager), Charlie (Tech Lead)
  • Developers Group: Bob (Engineer), Charlie (also in Developers), Diana (Engineer)
  • Marketing Group: Eve (Marketing Manager)

What Each Person Sees​

Alice (Administrator):

  • Full access to all company resources
  • Can manage all users and groups
  • Can modify company settings

Charlie (Administrator + Developer):

  • Has combined permissions from both groups
  • Can perform administrative tasks
  • Can also work with development resources

Bob (Developer only):

  • Access to development resources
  • Cannot modify user permissions
  • Cannot access administrative functions

Eve (Marketing only):

  • Access to marketing resources
  • Cannot see development data (unless permissions allow)
  • Cannot perform administrative tasks

Best Practices​

1. Use Groups for Organization​

Organize your users with meaningful groups:

Company: Acme Corp
├── Administrators Group - Full system access
├── Engineering Group - Development resources
├── Marketing Group - Marketing resources
└── Viewers Group - Read-only access

2. Define Clear Permission Boundaries​

Within your company, use groups to define what users can do:

Engineering Group
├── Can manage code repositories
├── Can deploy to staging
└── Can view production logs

Marketing Group
├── Can manage campaigns
├── Can view analytics
└── Cannot access code repositories

3. Keep It Simple​

Start with a simple structure and add complexity only when needed:

Phase 1: Basic groups (Administrators, Users, Viewers)
Phase 2: Add department-specific groups
Phase 3: Add specialized role groups as needed

4. Name Things Clearly​

Use descriptive names that make the structure obvious:

  • ✅ "Engineering Department"
  • ❌ "Group 1"
  • ✅ "Read-Only Viewers"
  • ❌ "Group A"

Security Considerations​

What Console Guarantees​

  • Complete isolation: No cross-company data access
  • Secure authentication: Multiple auth methods with optional 2FA
  • Audit logging: All access is logged
  • Automatic filtering: Data is filtered by company automatically

What You Should Do​

  1. Regularly review access: Check who has access to what
  2. Deactivate promptly: Remove access when users leave
  3. Use appropriate groups: Don't give users access they don't need
  4. Enable 2FA: Require two-factor authentication for sensitive roles

Next Steps​

Now that you understand multi-tenancy, learn about:

For Developers

Interested in how multi-tenancy works at the API level? See the API Multi-Tenancy Concepts for technical details.

Last updated on