Roles & Access Control
How organization roles and project roles combine to decide what each person can do in 8090 Software Factory.
8090 Software Factory decides access with two independent layers. Your organization role says who you are across the whole organization. Your project role says what you can do inside a single project. Both are checked on every action.
The two layers
| Layer | Roles | What it governs |
|---|---|---|
| Organization role | View, Member, Admin (plus Super Admin, an 8090-internal role) | Organization-wide abilities, and the ceiling on how much project access you can hold. |
| Project role | Viewer, Editor, Owner, or a custom role | What you can do inside one project. |
Access to a project's content is governed by your project role, not your organization role. Being a Member of the organization grants nothing inside a project until someone assigns you a project role.
Read each layer in detail:
How access is decided
View is capped at Viewer
Someone with the View role never resolves to more than the Viewer project role, on any project. Assigning a higher project role, or a richer custom role, does not lift the cap. This is the one rule that holds access below what a role would otherwise grant.
Organization Admins act as Owner everywhere
An organization Admin holds Owner-level access on every project through their organization role, an implicit Owner without a membership record. Because that access is implicit, an Admin who has no explicit project assignment does not appear in the project's member list, which lists explicit assignments only. When an Admin does hold an explicit assignment, the member list relabels them to Owner. Either way, removing an Admin's explicit project membership does not remove this access.
The project creator is an Owner
Whoever creates a project becomes its Owner. A project can have more than one Owner. If the last Owner is removed, organization Admins keep their implicit access and can reassign ownership.
Access only ever adds
Roles build access up, they never subtract it. A built-in role gives a fixed bundle of permissions. A custom role starts from a base and layers module access on top. There is no way to revoke a single permission below a base, so to give less, start from a lower base. The one rule that lowers access is the View to Viewer ceiling.
An agent can never do more than the person driving it
Every agent action runs as the person who triggered it and inherits exactly that person's permissions. If you cannot do something by hand, the agent cannot do it for you. Automations run with their author's permissions, and any restriction placed on an automation can only narrow what it may create or edit, never widen it. This is why a View-seat person can never use an agent to act above Viewer.
What a denied action looks like
- A module you cannot open shows You don't have access to this module in the navigation.
- When an agent action needs a higher tier than you hold, the run reports a short line naming the tier and module, such as Missing editor permissions in Work Orders.
- Controls for actions above your tier are disabled or do not appear.
Where roles are managed
Organization Admins manage roles at Settings → Organization → Manage Roles. The page has a Built-in Project Roles section and a Custom Roles table.
Related
Next, learn about Organization roles.