Platform Permissions
Most access in metamorphOS is decided per process. A step names a role, the role is filled by a person, and that person reaches that instance and nothing else. Platform permissions are the other kind of access. They are six named capabilities that exist in every workspace, always mean the same thing, and are what you grant when someone needs to work across the workspace rather than inside one process.
The six permissions
| Permission | What it opens |
|---|---|
| Processes | Read every process definition, every version of it, and the Builder. |
| Datastores | Read every datastore and the structure it defines. |
| Integrations | Read how every connector is configured, including its credential and OAuth status. |
| User Management | Onboard and offboard people, and grant or revoke their permissions. |
| Monitoring | Watch activity and health across running processes. |
| Billing | See usage against quota, and the plan this workspace is on. |
Granting one
A platform permission is an authorization like any other. Each of the six is carried by an authority that already exists in your workspace, so you grant it the ordinary way: open Users, pick the person, add the authority. Revoking is the same move backwards.
The Platform permissions card on the Permissions fold lists all six together with who currently holds each one, so you can answer “who can reach the Builder?” without reading down a table of authorities.
The six are not per-process settings and there is no seventh you can create. Anything narrower than a whole workspace is a role inside a process, not a platform permission.
Definitions are not data
This is the part that surprises people.
Processes, Datastores and Integrations open the design of a thing. They never open what is running through it.
Someone holding Processes can:
- open any process in the Builder and read how it is built,
- read every version of it,
- see which steps exist, which roles they route to, and what fields they collect.
The same person cannot:
- open a running instance of any of those processes,
- read what somebody typed into a form, or what a generated document says,
- see the history of a case they were not part of.
Datastores works the same way: it shows you a datastore and the fields it defines, never the records stored in it. Integrations covers how a connector is set up and whether its credentials are valid.
Reaching a running case is decided by that case’s own access rules, which come from the roles on its process. Holding Processes is not participation in any process, so it does not add up to instance access. If someone genuinely needs to read live cases, that has to be arranged on the process itself, as a role, where it is visible as one.
The split only does its work where there is an access rule to enforce. An instance whose process names nobody is reachable by everyone in the workspace, platform permission or not. Put roles on the processes that carry confidential data.
Reading is not changing
Processes, Datastores and Integrations are read capabilities. They open a design so it can be reviewed, compared across versions and understood. Creating, editing and deploying still requires Admin.
Grant with that in mind. Processes makes someone a reader of how the workspace is built, which is what an analyst, an auditor or a new joiner actually needs. It does not make them a builder, and it is not a way to give someone oversight of live work either. Monitoring is the permission for that, and even it reports activity rather than case contents.
Admin holds all six
Admin implies every platform permission. An admin does not appear as a holder of the six authorities, because they were never given them: they have the capability without holding the authority. The Platform permissions card keeps the two apart on purpose. The holder column lists the people who actually hold each authority, and admins are counted quietly beside them as N via Admin.
The difference shows up when you take access away:
- To take a permission off a holder, remove that authority from them, and the other five are untouched.
- To take it off an admin, you have to remove Admin itself. There is no way to keep Admin and drop one of the six.
That asymmetry is the practical argument for granting narrowly. Someone who needs to read how processes are built should get Processes. Handing them Admin to save a step hands them User Management as well, permanently, until Admin comes off again.
What Monitoring reports
Monitoring is the one capability that looks at running work, so it is worth knowing where it stops. It reports the shape of activity: which processes are busy, which instances moved recently, who acted and when, and which external tasks are still open. It does not carry the data inside those instances. Names and timings cross; form values, documents and payloads do not.
The one business value that does cross is the instance name, because that is the handle your workspace chose for a case (often an order or ticket number). If your naming template puts something confidential in that name, a monitor holder sees it.
Billing today
Billing unlocks exactly one thing: the plan this workspace is on and its step usage against quota. There is no separate billing area yet, and that same figure is also open to Monitoring holders, so granting Billing on its own is mainly a statement about who is accountable for cost. It starts carrying weight when a billing surface arrives.
Choosing who holds what
| The person | Grant |
|---|---|
| Reviews or audits how the workspace is built | Processes, plus Datastores for the data shapes |
| Looks after how connectors are configured | Integrations |
| Runs onboarding and offboarding | User Management |
| Watches whether work is flowing | Monitoring |
| Answers “what is this costing us?” | Billing |
| Needs to read live cases | None of these. Put them in the process, as a role. |
| Builds, deploys and runs the workspace | Admin, granted sparingly |