Understanding Applications Permission Scopes
Applications resources form a hierarchy: workspaces contain applications, and applications contain pages. A permission scope determines where a grant starts and which descendant resources it covers.
Before you start
- After the permission mismatch is fixed, open Applications > More > Permissions. Do not use a direct route as a workaround.
- Identify the exact workspaces, applications, or pages the principal needs.
- Review existing grants, including role grants, before adding another one.
Scope hierarchy
Global
└── Workspace
└── Application
└── Page
| Scope | Coverage | Use it when |
|---|---|---|
| Global | Every current Applications workspace, application, and page | A trusted principal needs organization-wide Applications access. |
| Workspace | The selected workspace, all its applications, and all their pages | A team owns or uses an entire workspace. |
| Application | The selected application and all its pages; its parent workspace remains visible for navigation | A team needs one complete application. |
| Page | The selected page; its parent application and workspace remain visible for navigation | A person needs one specific page. |
Parent containers added for navigation do not expand a Page grant to sibling pages or an Application grant to sibling applications.
Choose and save a scope
- In Grant Access, choose the user or role.
- Under Resource scope, select Global, Workspace, Application, or Page.
- If the scope is not Global, select the resource:
- Workspace scope displays a workspace multi-select.
- Application scope displays workspace choices first, then applications in the selected workspaces.
- Page scope displays workspaces, then applications, then pages. Default pages are marked (default).
- Select View, Edit, and/or Open in Builder.
- Select Save Permission.
- Verify the result in Active Grants by selecting the corresponding scope tab.
You can select multiple resources in one submission. RAPTIX creates or updates one grant per selected resource.
How overlapping grants work
Direct user grants and grants inherited through roles are combined. Applicable capabilities are additive.
For example:
- A Workspace View grant plus a Page Edit grant makes the whole workspace visible and allows editing on the specified page, subject to plan and feature access.
- A Global View grant already provides visibility everywhere; an additional Page View grant does not narrow it.
- Removing an Application grant does not remove access supplied by a Workspace or role grant.
There is no deny grant in this screen. A narrower row cannot override a broader grant to remove access.
Selecting the right scope
- Choose Page for isolated access to one screen.
- Choose Application when every page in one application is required.
- Choose Workspace when the team genuinely needs every application in a workspace.
- Reserve Global for trusted principals with an organization-wide responsibility.
- Prefer a role grant when the same scope should follow team membership.
Review Global and Workspace grants regularly because they have the widest effect.
Troubleshooting
The Application or Page picker does not appear
Select its parent first. Applications appear only after at least one workspace is selected; pages appear only after at least one application is selected.
A page remains hidden after an Edit grant
Edit does not replace View in the explorer. Add View on an applicable grant if the page must be discoverable.
Removing a narrow grant did not remove access
Review direct and role grants at Global, Workspace, and Application scopes. Any applicable View grant can keep the resource visible.
A parent workspace is visible even though only one page was granted
This is expected. RAPTIX exposes the parent path so the user can navigate to the granted page; sibling pages remain restricted unless another grant covers them.