Compass - Nimbly Documentation

Roles Backend

2 min read

1. Overview

The roles collection in the nimbly database is used to manage user roles and permissions for each organization. Each document defines a specific role, the users assigned to that role, and the permissions granted through access control.

Roles are created and managed via the Admin interface, while the permissions tied to those roles are defined in the Access Control.

This setup allows Nimbly to implement flexible and scalable role-based access control (RBAC) across different organizations and user types.

To learn more about how roles work in the system, refer to the User Roles.

2. Schema Definition

 
{
  _id: ObjectId, // Unique identifier for the role document
  organizationID: string, // ID of the organization this role belongs to
  level: number, // Numeric level to define role hierarchy or access depth
  label: string, // Human-readable label for the role (e.g., 'Account Holder')
  role: string, // Unique identifier or key for the role (e.g., 'account_holder')
  users: string[], // List of user IDs assigned to this role
  resources: [
    {
      _id: ObjectId, // Unique ID for the resource permission entry
      resource: string, // Resource string following namespace-style convention
      permission: string[] // List of allowed actions: ['view', 'edit', etc.]
    }
  ],
  deleted: boolean, // Soft delete flag (false = active, true = deleted)
  updatedAt: Date, // Timestamp of the last update to the role
  __v: number // Internal version key managed by Mongoose (or ODM)
}

2.1. users Field :

  • Contains an array of user IDs (string) who are assigned this specific role.
  • This enables managing multiple users with the same access level in a centralized way.

2.2. resources Field :

  • Each entry in resources defines what permissions are granted to the users of the role.
  • resource: Defines the permission namespace (e.g., setting-permission:general:all)
  • permission: Array containing permission types like view, edit, etc.
  • Permissions are defined and managed from the Access Control Settings interface.

2.3. level Field :

  • Represents the priority or authority level of the role.

  • Higher values indicate more powerful roles.

  • This is commonly used to control access across UI elements, decision logic, or escalations.

  • Example usage:

    • level: 99 → Full access (e.g., Account Holder or Super Admin)
    • level: 10 → Limited access (e.g., Viewer or Auditor)

  • You can compare levels to determine role precedence in custom workflows or logic.

role #connects/platform #connects/feature

Graph View

Backlinks