Root Orgs, Teams, and Resource Sharing
Monad organizes work into a hierarchy of organizations. A root org sits at the top, teams are organizations nested underneath it, role-based access control (RBAC) governs what each user can do inside a single org, and resource sharing lets a root org share resources with its teams. This guide explains how those pieces relate; each has its own reference documentation, linked inline.
The organization hierarchy
A team is a Monad sub-organization nested underneath your root org — the same relationship the docs also describe as a top-level organization and its child organizations. Each org is an isolation boundary: connectors, pipelines, and secrets belong to one org, and API calls are scoped to that org, so a credential for one org cannot reach another's data.
The mental model:
- Hierarchy is the shape — a root org with teams beneath it.
- RBAC governs permissions within an org.
- Resource sharing is a one-way link between a singular root org and its sub-orgs (teams).
For how this maps to API scoping and multi-tenant setups, see Auth & Tenancy.
Roles and access control
Every organization uses RBAC, and roles are scoped to a single organization — each user has exactly one role per org. Roles are made up of granular permissions grouped by resource.
Four protected default roles ship with every org and cannot be edited or deleted:
- System Administrator — full access, including managing users, roles, org settings, and SSO.
- Contributor — read/write on pipelines, inputs, outputs, transforms, enrichments, secrets, API keys, and alert rules, and can view org logs and metrics; cannot manage users, roles, settings, or SSO.
- Reader — read-only across those resources.
- Data Sender — publish-only: can send data to a pipeline's ingest endpoint (
pipeline:data:write) and nothing else. Intended for systems that ship data into Monad.
You can also create custom roles from any subset of permissions, with one guardrail: you can only grant permissions your own role already has, so a role can never escalate privileges. API keys are assigned a role too, using the same permission system. The full per-permission matrix and user-management details are in Organization RBAC.
Sharing resources across the hierarchy
Resource sharing lets a root org make certain resources available to its teams. Sharing flows one way — from a root org down to its teams — and a team cannot re-share what it receives.
- What can be shared: inputs, outputs, transforms, enrichments, and secrets.
- Read-only to the recipient: a team can use a shared resource in its pipelines but cannot edit or delete it; only the owning org can change it. Sharing a secret lets a team reference a credential without ever seeing its value.
- In-use protection: you cannot unshare a resource while a team still has something using it.
- Share with future teams: an option to automatically share with teams added later grants access to teams created after the setting is enabled.
Step-by-step instructions and worked scenarios — centrally managed credentials, a standard destination for every team, day-one access for new teams, and winding access down safely — are in Resource Sharing.