Skip to main content

​
Roles & Permissions

The Zild Platform enforces access control through a Role-Based Access Control (RBAC) model. All access is:
  • Authenticated
  • Tenant-scoped
  • Role-based
  • Explicitly authorized
Permissions are evaluated on every protected action.

​
Access Control Model

Zild applies authorization in three layers:
  1. Tenant isolation
  2. Role-based permission evaluation
  3. Conversation-level access control
Every request must pass:
  • Identity authentication
  • Tenant resolution
  • Role validation
  • Resource-level permission check
Access is denied by default unless explicitly permitted.

​
Tenant Isolation

Each user belongs to a single Tenant. Permissions are always evaluated inside that Tenant’s boundary. This guarantees:
  • No cross-tenant data access
  • No cross-tenant configuration access
  • No cross-tenant conversation visibility
Tenant isolation is enforced at:
  • API layer
  • Admin interface
  • Data access layer
  • Workflow execution layer

​
Role Model Overview

Zild defines three primary roles:
  1. Administrator
  2. Supervisor
  3. User
Each role has a clearly defined scope of access.

​
Administrator

The Administrator has full access within the Tenant. This role is intended for system owners and technical administrators.

​
Permissions

Administrators can:
  • Manage users and assign roles
  • Configure Apps (WhatsApp, Voice, Webchat)
  • Create and edit Agents
  • Create and manage Workflows
  • Configure Integrations
  • View and manage all Conversations
  • Access analytics and reports
  • Rotate API keys
  • Modify Tenant settings
Administrators are not restricted by group or conversation ownership. This role should be limited to trusted personnel.

​
Supervisor

The Supervisor has operational visibility and control over a specific group. Supervisors manage teams and oversee conversation quality.

​
Permissions

Supervisors can:
  • View conversations assigned to their group
  • Reassign conversations within their group
  • Escalate conversations
  • Close conversations
  • Monitor conversation performance
  • View group-level analytics
Supervisors cannot:
  • Modify Tenant settings
  • Manage API credentials
  • Create or modify system-level integrations
  • Access conversations outside their assigned group

​
User

The User is an operational role with limited scope. Users typically represent front-line agents.

​
Permissions

Users can:
  • View conversations assigned to them
  • Respond to their assigned conversations
  • Escalate conversations
  • Close conversations
Users cannot:
  • View conversations assigned to other users
  • Access conversations outside their group
  • Modify system configuration
  • Manage Agents, Apps, or Workflows
  • Access Tenant-level settings
Access is strictly limited to conversations explicitly assigned to them.

​
Group-Based Access Control

Supervisors and Users operate within groups. A group typically represents:
  • A department
  • A support team
  • A sales team
  • A business unit
Conversation visibility rules:
  • Administrator → All conversations
  • Supervisor → Conversations within their group
  • User → Conversations assigned to them only
This ensures operational segmentation while preserving tenant-wide isolation.

​
Conversation-Level Authorization

When a conversation is accessed:
  1. User identity is authenticated
  2. Tenant is resolved
  3. Role is identified
  4. Group association is checked (if applicable)
  5. Assignment ownership is validated
Access is granted only if all checks pass.

​
Security Enforcement

Authorization checks are enforced at:
  • API endpoints
  • Admin interface actions
  • Conversation retrieval queries
  • Workflow execution triggers
Unauthorized access attempts are rejected and logged.

​
Audit Logging

The platform logs security-relevant actions, including:
  • Role assignments
  • User creation and modification
  • Conversation reassignment
  • Escalation actions
  • Configuration changes
This supports:
  • Operational traceability
  • Compliance auditing
  • Security investigation

​
Principle of Least Privilege

Zild follows the principle of least privilege:
  • Users only access their own conversations
  • Supervisors only access their group
  • Administrators manage system configuration
This reduces risk exposure and prevents unauthorized data access.

​
Summary

The Zild permission model is structured around:
  • Tenant isolation
  • Role-based access control
  • Group-level segmentation
  • Conversation-level ownership enforcement
Role capabilities are clearly defined:
  • Administrator — Full access
  • Supervisor — Group-level visibility
  • User — Own conversations only
This model ensures operational efficiency while maintaining strict access boundaries.