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).
• A token is never asked for a second factor, and the rules for sign-in duration do not end it. One rule: a user without a second factor cannot create a new token while their own organization requires two-factor authentication (2FA).

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

Two-Factor Requirement on Top of Roles

Roles decide which plants you may reach. An organization can add one condition on top: it can require two-factor authentication (2FA) for access to its plants.

• A role grants the plant. The requirement decides whether it is shown to you. If the organization that owns a plant requires 2FA and your account has no second factor (authenticator app or passkey), you do not see that organization's plants — whatever role you hold on them.
• Nothing is taken away. Your roles and grants stay as they are. You stay signed in, and a hint in the header tells you to enable 2FA. As soon as you enable it, the plants are back.
• The plant's owner decides. The requirement applies to everyone who reaches the plant: the organization's own members and the users of a cooperation partner.

Who sets the requirement and what exactly is hidden is described on the Organization Security Policy page.

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.

Shared content of the organization. Admins, Moderators and both Asset Manager roles create, duplicate, change and delete the organization's report templates, chapters and metrics, its Data Export templates and formulas, and the rules, receivers, templates and silences of the Alert Manager; Members see and use them. An item marked Private is changed only by its creator, an Admin or a Moderator — see Reports and Alert Manager. Direct marketers stay with Admins and Moderators.

Job-Based Resource Permissions

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

Security Officer is grant-only. No organization role maps to it, so nobody becomes a security officer by joining an organization — it is handed out deliberately, per plant or per portfolio, or shared through a cooperation.

Client is grant-only too, and the only role whose grant can narrow an account: grants add up, so a Member who receives a Client grant keeps the Member's Viewer access — the limited view only takes effect for an External member or a cooperation share. A Client grant can carry an expiry date.

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.
• Metric Export — Limited to reading the data export: metrics as time series, export templates, the metric catalog, plant information and events. It cannot change anything.
• Timeseries Database — Access to the time-series endpoints for reading the raw measurement series.

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.

If the organization that owns a shared plant requires 2FA, this applies to the receiving Admin and to every delegated member as well — see Two-Factor Requirement on Top of Roles.

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, billing and tariffs without any remote access to the plant networks.

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
• Organization Security Policy — the 2FA requirement and sign-in rules an organization sets
• 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