The Access screen
Assign a role, scope it to one project, and read exactly where a person's access came from
Overview
Access is the screen in MagOne Studio that answers "who can do what in this workspace, and why". Open it from the organization menu.
It is where an org admin grants one action on one project without involving a platform superadmin. Everything on this screen calls the same organization-scoped API the Admin Portal uses, reached by the people who actually own the workspace.
This is deliberately the narrower screen. It shows members, their roles, and the grants those produce, because that is the whole of what an org admin needs, and every control on it is one they may already use.
The Admin Portal keeps the platform view: apps, entitlements, enforcement modes, and cross-organization work. See Access control overview.
What you can do here
| Task | How |
|---|---|
| See everyone in the organization | The member list, with search |
| See what one person holds, and from where | Select them. The detail panel shows every role and its source. |
| Give someone a role | Assign role, then pick the role and the scope |
| Take a role away | Revoke it from the detail panel |
| Remove someone from a project | From the detail panel |
Assigning a role
Select the person
Find them in the member list. The detail panel on the right shows what they already hold.
Click Assign role
The panel shows the roles available in this organization: the seeded roles, and any your organization has authored.
Choose the scope
This is the control the screen exists for.
- One project. The role's project-level grants are pinned to that project. This is the default, because the narrow answer is usually the right one.
- Across the workspace. The role's grants stay level-wide wildcards, applying on every project the person can already reach.
The same shared role can therefore mean Builder on one project and nothing on another, which is what makes seeded roles reusable.
Set an expiry, if the access is temporary
Expires (optional) takes a date and time, and the grant lapses on its own when it passes. Leave it empty for a permanent assignment.
An expired grant stops counting toward the person's permissions at the next decision. Nothing has to run, and nobody has to remember to revoke it.
This is the control to reach for with contractors, incident response, and temporary cover, because it removes the access even if everyone forgets.
Read the warning if there is one
If the person already holds one of the four project tiers on that project, assigning a second replaces the first. The panel tells you before it happens. See below.
Confirm, then check the detail panel
The new role appears immediately. Access changes at the next decision, with no cache to wait for.
One project tier per project
The four project tiers, Viewer, Operator, Builder and Admin, are mutually exclusive on a given project. A person holds exactly one.
Assigning a second project tier on the same project replaces the first rather than adding to it. The server has always behaved this way, and the screen now says so before you confirm.
This only applies to the four project tiers. Other roles, including ones you author, stack normally.
Because the tiers are cumulative, this is almost never a problem: assigning Builder to an existing Operator is an upgrade, not a loss. Assigning Operator to an existing Builder is a downgrade, which the warning is there to catch.
Reading the detail panel
The detail panel is the most useful part of the screen, because it shows access and its source.
A person's effective access is the union of four things, minus every deny:
| Source | Shown as |
|---|---|
| The Default role | Held by everyone, with no assignment |
| Roles seeded from membership | Attributed to the organization or project membership that created them |
| Roles assigned directly | Attributed to the assignment, with its scope |
| Roles carried by a group | Attributed to the group |
This is why you should read the panel before concluding that a role is wrong. A person who seems to have too much access usually has a second source.
When access does not change as expected
The most common surprise on this screen has one cause: a wildcard grant does not establish access to a new project.
| What you did | What happens |
|---|---|
| Assigned Project Operator across the workspace | They may run use cases on the projects they can already reach |
| Assigned Project Operator scoped to project A | They may reach project A, and run use cases there |
If someone cannot see a project at all, scope the assignment to that project, or add them to it. See wildcard and explicit targets.
What you cannot do here
The grant ceiling applies here as everywhere. If you do not hold an action, you cannot hand it out. Denies are exempt, because a deny cannot widen access.
Role authoring lives on the Access Control page in the Admin Portal. This screen assigns roles that already exist.
Enforcement is per organization and per action, set by a platform administrator.
Cross-organization group assignment is a platform administrator task, because its effects reach outside your organization.
Some permissions are scoped to the use case rather than the object underneath it. An inbound_webhook.manage grant covers every inbound webhook on that use case. Per-object permissioning is not expressible today.
Troubleshooting
Cause: You do not hold the action that lets you read access in this organization.
Fix: Ask an org owner or a platform administrator.
Cause: Both were project tiers on the same project, and the second replaced the first.
Fix: Re-assign the tier you want. Remember the tiers are cumulative, so you only ever need the highest one.
Causes to check: another group carries a role granting the same action, the Default role grants it to everyone, or they hold a second direct assignment.
Fix: Read the detail panel, which attributes each piece to its source.
Cause: Membership should seed a role at the moment it is created. If nothing was written, the person holds no role at all, which fails open and is logged.
Fix: Assign a role explicitly. A membership path that writes no role is worth reporting.
Cause: The screen hides controls you cannot use. A person who cannot author roles does not see role authoring.