Permission System

The Mirox platform controls access through a layered, role-based permission model that gives you precise control over who can see and change which plants — without forcing you to manage individual rights one by one. Roles do the grouping; the hierarchy does the inheritance.

Permission Philosophy

The permission system is built on a few principles that keep access both secure and easy to reason about:

1. Hierarchical Inheritance — Access follows the natural hierarchy of resources and organizations: grant once high up, and it flows down.
2. Least Privilege — Every role carries only the rights its job actually needs.
3. Separation of Concerns — Organizational standing and resource access are two distinct axes, so you can give someone a senior org role without exposing every plant, and vice versa.
4. Explicit Assignment — Access is granted on purpose, never assumed.
5. Context Awareness — The same person can have different rights on different plants.

Together these keep a secure yet flexible approach to managing access across the Mirox platform.

Permission Layers

A request passes through a sequence of checks. Each layer answers one question; all relevant layers must agree before access is granted.

Note: the API Layer only applies to requests authenticated with an API token; interactive sessions skip straight to the System Layer.

The layers:

• API Layer (orange) — Only for API token requests. Validates the token and applies its permission group, which can only ever narrow what the token's owner could already do.
• System Layer (red) — The first gate for every request. It establishes platform-level standing (regular user vs. platform administrator) and protects system-critical operations regardless of any other layer.
• Organization Layer (blue) — Confirms you belong to the organization that owns the resource and applies your organization role.
• Job Layer (green) — The most granular check: it decides what you may do on a specific plant or portfolio.

The diagram below shows the common combinations. Organization-wide data needs the organization check; a single plant needs the job check; many requests need both.

System Permission Layer

The system layer is the first security gate. It distinguishes platform administrators from regular users and protects system-wide operations:

• Platform administrators can perform system-wide operations.
• Regular users cannot take actions that affect the platform itself.
• This layer does not evaluate feature-level access (such as report generation) — that happens further down.

System integrity stays protected even if a finer-grained check is misconfigured.

Organization Permission Layer

Every user belongs to exactly one organization, which is the gateway to resources:

• Organizations own resources (portfolios and parks).
• You receive your baseline access through your organization role.
• Organizations can establish cooperation agreements to share specific resources across the organization boundary.

This layer enforces organizational boundaries: you only reach resources your organization owns or has been granted through a cooperation.

Resource (Job) Permission Layer

The most granular level controls what you can do on an individual plant or portfolio. Access here is expressed as a job role (see below):

• Your organization role provides a default job role on every owned resource.
• Organizations can override that default by granting you a specific job role on a specific resource — broader or narrower than your default.
• A direct grant always wins over the inherited default, so exceptions are easy.

This layer enables precise, per-plant control without changing anyone's organization role.

API Token Permission Layer

An optional layer for automation and integrations:

• API tokens are created by users to drive scripts and external systems.
• A token can never exceed the permissions of the user who created it — it only restricts.
• A token is bound to a permission group that scopes it to a feature area (see API Permission Groups).

This keeps automation secure while honoring least privilege. For details, see the API Tokens feature documentation.

Role-Based Access Control System

Mirox uses Role-Based Access Control (RBAC) with predefined roles on three axes: a platform-wide system role, an organization role, and per-resource job roles.

System Roles

System roles define platform-wide standing:

• Administrator — Platform staff with access to system-wide operations and configuration.
• User — The standard role for everyone using the platform; no administrative privileges.

Organization Roles

Your organization role is your default standing inside your organization. The two manager roles are the core of the current permission structure: they let you delegate senior responsibility without handing over full moderator control.

The two manager roles are siblings — peers under Moderator, one technical and one commercial. This split lets a single organization separate engineering ownership from contract and billing ownership cleanly.

Job-Based Resource Permissions

Job roles define what a user can do on a specific plant or portfolio, independent of their organization role:

The token in parentheses is the identifier used in API grants and cooperation shares; everywhere in the interface you see the verbose label.

API Permission Groups

API tokens are assigned to exactly one permission group that scopes what the token can reach:

• Full Access — The same permissions as the creating user, within their scope.
• Reporting — Limited to reporting features: generating reports and exporting data.
• Timeseries Database — Access to the time-series endpoints for programmatic data retrieval with MiroxQL.

For use cases and examples, see the API Tokens feature documentation.

Permission Inheritance

Access flows down the resource hierarchy, so you grant high and refine low:

Organization
├── Organization Role (your default standing)
│
├── Portfolio 1
│   ├── Inherits organization-level access
│   ├── Portfolio-specific grants (optional)
│   │
│   ├── Park A
│   │   ├── Inherits portfolio access
│   │   └── Park-specific grants (optional)
│   │
│   └── Park B
│       ├── Inherits portfolio access
│       └── Park-specific grants (optional)
│
└── Portfolio 2
    └── Park C
        └── Inherits portfolio access

This inheritance model means:

1. Access from your organization role applies to all portfolios and parks your organization owns.
2. A grant at the portfolio level applies to every park in that portfolio.
3. A grant at a single park refines access for that park only, overriding the inherited default.

Organization Role to Job Role Mapping

When you access a resource, your organization role automatically determines your default job role:

This separation keeps resource permissions (job roles) distinct from organizational standing. Your organization role sets the default, but explicit per-resource grants can raise or lower it for any individual plant.

Organization Cooperation

Organizations can establish cooperation agreements to share specific resources across the organization boundary:

1. Two organizations form a formal cooperation.
2. The resource-owning organization grants specific access using job roles.
3. What is shared at the cooperation level caps what the receiving organization can then delegate to its own members.
4. All access remains auditable and can be revoked by the resource owner at any time.

For the full rules on how shared access is bounded and delegated, see Cooperation Restrictions.

Best Practices

For effective permission management in Mirox:

1. Use the Standard Roles — The predefined organization and job roles cover the large majority of real situations.
2. Match the Manager to the Responsibility — Use the Asset Manager (Technical) role for engineering ownership and the Asset Manager (Commercial) role for contract and billing ownership.
3. Assign at the Highest Appropriate Level — Grant at the organization or portfolio level when access should apply broadly; refine at the park level only for genuine exceptions.
4. Review Regularly — Audit member roles and per-resource grants periodically, and set expiration dates for time-limited access.
5. Verify Access — Confirm a configuration by checking what a given member can actually reach before relying on it.

Practical Examples

Multi-Site Management

An organization managing several solar parks might set up:

• An operations lead as Admin, with full control of the organization.
• An engineering owner as Asset Manager (Technical), handling component health, events, and tickets across all plants.
• A finance owner as Asset Manager (Commercial), managing contracts and billing without touching technical configuration.

Contractor Access

A maintenance contractor invited from outside might receive:

• An External organization role with a Technical Manager or Viewer job role on the specific parks they service.
• A per-resource grant scoped only to those plants.
• An expiration date so access ends automatically when the engagement does.

Investor Visibility

Investors can be given:

• A Member or External organization role with a Viewer job role on specific portfolios.
• Read access to performance and report data, with no management capabilities.

Related Features

• Cooperation Restrictions — how shared access is bounded between cooperating organizations
• Cooperations — sharing plants and portfolios across the organization boundary
• Invitations — inviting members and assigning their organization role
• API Tokens — scoped tokens for automation and integrations
• Audit Log — who accessed which plant devices and when
• Tickets — the human work-management layer gated by job role