Roles and permissions
This feature is still being finalized by Development.
Roles decide which screens a person can open. A screen that needs a view permission none of
their roles grants is unavailable in the navigation, and opening it by link shows an access-denied
panel instead. The home dashboard, Vision and Environments need no permission to open.
In these areas, roles also decide every action, and lists show only what the role's scopes reach: workflows and their deployments, scripts and the script catalog, the Toolkit (properties, thresholds, resources, calendars, frequencies and tags), service requests, their categories and their deployments, the Self Service portal, Vision cards, notifications, roles, workspaces and custom fields. An action the role does not grant is refused, even when it is requested without going through the screen. Someone who holds no role can do nothing in these areas.
Events are checked against the person who sends or saves them. See What an event is refused for.
In these areas, a role decides whether the screen is offered, but not what can be done there: Processes (every action on workflow and job instances), Agents, agent pools and plugins, the Event Log, saved reports, Vision's live view, and Environments, which has no permission at all. Anyone signed in to your tenant can use these actions, and their lists are not narrowed by a role's scopes.
Connections have moved out of that list — see Connections are checked, and the grant must be tenant-wide.
Permission checks used to let every signed-in request through. Review your roles: an account that worked only because nothing was being checked now needs the grant in the areas that are checked.
Task walkthrough: Manage roles and permissions. This page is the full configuration and troubleshooting reference.
Roles
| Field | Notes |
|---|---|
name | Unique per tenant, and constrained — see What a role can be named. |
description | Optional. |
isSystem | System roles (e.g. Administrator) are immutable. |
permissions | Catalog permission IDs (<objectType>.<action>). |
scopes | Where the role applies (workspace × environment tuples). |
The Administrator role is seeded per tenant with all permissions and a wildcard scope; it can't be modified. Roles can be duplicated.
Where a role is edited
Roles live on one page. The Roles list holds every role, and creating or editing one happens in a dialog over the list — there is no separate role page to open and come back from.
| On the Roles list | What it does |
|---|---|
| New Role | Opens the editor dialog empty. |
| The row menu (⋮, revealed on hover) | Edit, Duplicate, and Delete. Delete is unavailable on a system role, because the platform refuses to delete one. |
| Double-clicking a row | Opens the editor for that role. |
| Event Identities | Goes to the Event Identities list. Always offered — the destination explains an unconfigured tenant itself. |
| The status line | The tenant's role-sync status, when the identity integration is configured. See Keeping roles in step with the identity system. |
The dialog is addressed by URL, not held in the page's memory: /roles/new and /roles/<id>
render the list with the dialog already open. A link to a role from
global search therefore still works, and Back closes the dialog rather than
leaving the page.
Inside the dialog, Name and Description stay pinned across the top and the rest sits behind a two-way switch:
| Section | Holds |
|---|---|
| Privileges | The permission matrix and the scope tuples — the two halves of one question, what may this role do, and where. |
| Members | Who holds the role: the Users / Groups section, and the read-only Event Identities that carry it. |
Two things about the dialog are worth knowing before you use it:
- Save is enabled only once something has changed, on a new role as well as an existing one, and closing with unsaved changes asks first.
- The permission matrix is one table, with the scope tiers as grouped rows under a header that stays put as you scroll. Checkboxes for the same action line up vertically across tiers, which they could not when each tier had a table of its own.
Administrator keeps up with the catalog
"All permissions" now means all of them including the ones added after your tenant was created. The role is topped up automatically: any catalog permission it does not already hold is granted the first time the platform touches your tenant after an upgrade, so a new object type's permissions reach Administrator without anyone doing anything.
This is worth knowing because it did not always work that way. The role used to be seeded once, with
the catalog as it stood on the day the tenant was created, and never revisited — and since the
public API refuses to edit a system role, there was no way to add the missing permissions by hand
either. On an older tenant that left Administrator genuinely short of the newest permissions, which
showed up in simulation as no_role_grants_action against a
permission the catalog plainly lists. If you have seen that, it is fixed, and no longer a reason to
contact support.
Two details worth being precise about:
- Grants are only ever added. Nothing Administrator already holds is taken away by the top-up.
- The top-up runs per tenant, once per platform start. If an upgrade has just been applied, simulation for Administrator is accurate from the first time anyone in your tenant uses the platform after it — not necessarily the instant the upgrade lands.
Permissions are the only thing reconciled this way. A role's scopes and description are still written once, when it is seeded; Administrator's wildcard scope already covers everything, so there is nothing for a later top-up to correct.
What a role can be named
A role name must be 3 to 23 characters of letters, digits, underscores and hyphens — no spaces and no other punctuation. Create, rename and duplicate all refuse anything else, with the same sentence in the form and from the API: Role name must be 3-23 characters using only letters, digits, underscores or hyphens.
The rule is narrow because the role's name is its name in the Continuous identity system, which is what lets a role hold members there. It is deliberately narrower than the rule for workspaces and environments, and it has no exemption for names already stored:
Such a role loads and grants exactly as before — nothing about who it applies to changes, and
nothing stops working. But the first time you edit it for any reason, the name field is in error and
the save is refused until the name conforms. Rename it deliberately rather than discovering it
mid-edit: a role called Workflow Designer becomes something like Workflow_Designer.
A non-conforming role is also left out of the sync below, so it cannot hold members in the identity system until it is renamed.
Duplicate seeds a legal name for you: the original with every run of disallowed characters folded
to one _, truncated to fit, and _copy appended — so duplicating Workflow Designer opens the
dialog on Workflow_Designer_copy rather than already in error.
Keeping roles in step with the identity system
Roles are mirrored into the Continuous identity system, so that a role defined here is the role members are assigned to there. The mirror is maintained for you: creating, renaming, deleting or duplicating a role sends the tenant's complete set of conforming roles. Editing only a role's permissions, scopes or description does not — there is nothing about those the identity system holds.
There is nothing to press. When the tenant's identity integration is configured, the Roles list shows a status line — Last synced 4m ago, or Roles have not been synced to IAM yet, or the reason the last attempt failed — and that line is reporting only.
A failed sync never fails the change that triggered it: the role is created, renamed or deleted regardless, and the failure is recorded. The platform then recovers by itself, when the thing that needs the sync is read:
| Reading | Retries the sync for |
|---|---|
| The Roles list's status | The whole tenant |
| Opening a role in the editor | That role |
| Reading a role's members | That role |
The retry runs before the read returns, so what you are shown is already the result of it — you do not have to reload, and there is no button to find. If the retry takes longer than about five seconds, the read returns what is recorded so far and the retry finishes in the background. These limits apply:
- It runs only for someone who may edit roles (
roles.edit). Someone who can only view roles sees the status as recorded, and triggers nothing. - It runs only for a tenant that has synced successfully at least once. A tenant whose sync has never succeeded is not retried by reading; its next role create, rename, delete or duplicate attempts the sync again.
- It only runs while the tenant or the role is actually unhealthy.
- After a failed attempt, it does not try again within a minute.
- It never breaks the read it runs ahead of. A sync that fails again just records why.
The identity system accepts at most 100 roles in one sync, so a tenant with more than 100 conforming roles is not synced at all — no role is sent — and the status line reports Last sync failed: more than 100 roles. Delete roles you no longer need to bring the tenant back to 100 or fewer.
You can no longer create your way past the cap. Creating or duplicating a role is refused with a conflict once the tenant already holds 100 roles, so the tenant cannot be pushed into the not-syncing state by adding one more. Earlier builds accepted the create and the whole tenant then stopped syncing.
A non-conforming role name is excluded from every sync payload, so no retry can help it — rename it instead. And when the recorded reason asks for an action in the Continuous console, that is not retried automatically: do the action first. The next role create, rename or delete clears the reason, so doing it in the other order hides the thing you still have to fix.
A tenant with no identity credential costs nothing here — no retry is attempted at all.
Every role change already ran a sync. The old Sync roles and Retry sync buttons only made an operator responsible for a retry the platform can do itself, so both are gone.
If you need to trigger one from a script, the API still offers it.
Deleting a role removes it here immediately, but the withdrawal upstream — telling the identity system the role is gone, and with it every member's access through it — happens on the next sync. If that sync fails, the role still exists upstream with its members.
So a deleted role's name stays reserved until a successful sync has actually withdrawn it. While it is reserved:
- Creating, duplicating or renaming a role to that name is refused with a conflict, naming the reservation.
- If the role was renamed before it was deleted, its old name is reserved too — that is the name it may still be under upstream.
- The reservation clears by itself on the first successful sync that no longer carries the role. Nothing has to be done by hand.
Without this, recreating the name with different permissions would silently rebind every former member of the old role to the new one. If a name you expect to be free is refused, look at the tenant's sync status: a reservation that will not clear means the sync is still failing.
Deleting a role says what its members lose, and when. The delete confirmation carries the sentence "Access granted by this role is withdrawn at each member's next sign-in", placed after cannot be undone and before the question, so you are told the consequence before you are asked to accept it. A delete also re-reads the sync status afterwards, so a withdrawal that failed at the identity system — the one state where the two disagree about who has access — appears on the list rather than waiting for your next visit.
Deleting is owned by the Roles list, wherever you start it: the editor dialog's Delete hands the role back to the list, so there is exactly one confirmation to read rather than two that could drift apart.
Mirroring a role is what makes it able to hold members. Who holds it is then edited on the Members section of the role editor — see Members.
Renaming a synced role moves its members with it
The identity system knows a role by an id, so the rename itself reaches it as an ordinary update — but membership there is held against the role's name, and whether it follows a rename is not guaranteed. The platform therefore moves it explicitly rather than assuming: it reads who holds the role under the old name, sends the rename, re-assigns each holder under the new name, then withdraws each from the old. The writes are one at a time and repeatable, so a run that stops part-way can be finished rather than restarted.
| What a member notices | On a native tenant, each holder is signed out once — their access is re-granted under the new name and their next sign-in picks it up. On an SSO tenant a group mapping is moved and nobody is signed out. |
| Changing only the capitalization | Not a move. The identity system compares role names case-insensitively, so only the display name changes, nobody is re-assigned and nobody is signed out. |
| A role with no members, or one never synced | Renames plainly, with no carry-over to do. |
| How long it takes | A rename waits for the move to finish. Reading the members, the rename itself and two writes per holder are all done under the tenant's lock, so a role with a thousand members can take several minutes and any other sync for that tenant waits behind it. |
The Roles list says when a rename is in flight — "A role rename is moving its members; a large role can take several minutes." That is progress, not a failure, and it is distinct from the Last sync failed line.
When a move is interrupted
A move can stop part-way — an outage, a lock that timed out, a member the identity system refuses. When it does:
- The next sync for that tenant finishes it — a sync triggered by another role change, or the automatic retry that runs when the role is opened. An ordinary run does not skip the unfinished move and clear it; it completes it.
- The old name is reserved until the move finishes. Creating a role, duplicating one, or renaming another role onto that name is refused while members may still be under it.
- A second rename of the same role is refused until its first move is done.
- A move that keeps failing is abandoned after five attempts, with the role left carrying a plain reason saying how many of how many members moved. The tenant syncs normally again and the role can be renamed again. Only a failure the identity system actually answered counts against those attempts — an unreachable host or an exhausted retry is the link being down, and an outage must not spend a move's allowance however many runs it spans.
- A move whose members cannot be read is refused rather than reported done. Most likely they were already carried across by the identity system; most likely is not a record, and whether membership follows a rename is the one thing this path refuses to assume. The role keeps a reason naming both names and the count, and the next successful sync clears it once an administrator has checked.
When a move ends without completing, the platform releases the old name here — but members may still be holding it in the identity system. Check there first. Creating a new role under that name before you have would hand it whatever is left over.
The role editor warns you before Save whenever the name has changed, the role is synced and it has members, naming the number that will be re-assigned and, on a native tenant, that they will be signed out once. It is a warning rather than a confirmation: unlike removing your own access, a rename is recoverable.
A role whose last sync failed takes the carry-over just the same but shows no warning. Renaming one is not wrong — just be aware the move will happen without being announced.
Event Identities
An event identity is a machine identity that submits events into the platform — the credential an agent or an external system presents, as opposed to a person's sign-in. They appear in two places, and the difference matters:
| Where | What you can do |
|---|---|
| The Event Identities action on the Roles list | Manage the identities themselves. Offered whatever your tenant's identity integration looks like, because the destination explains what it finds. |
| The Event Identities part of a role's Members section | Read only. It lists the identities that currently hold this role, each linking to its own page. |
A role is attached to an identity from the identity's own page, not from the role. The identity is the object being credentialed, so that is where the confirmation and the governance gate live — which is why the list inside the role editor is a read rather than an editor.
That list answers who holds this role whatever the role's sync status: it matches the tenant's identities on the role's name, so a role that has never synced simply has no holders rather than refusing to answer. It does need the tenant to have an identity credential, and it says so in its own words when there is none. Before a brand-new role has been created there is no name to match on, and it says that instead.
Event identity management is off, so the section reports "Event identity management is not switched on in this environment, so these identities cannot be managed yet." That is the expected answer, not a fault with your tenant, and nothing else on the Roles page is affected. It is off by default in every environment. To register an identity for an agent, see Agent-raised events.
Members
A role's members are edited in the role editor. The Members section is one of the editor's two halves, beside Privileges: it lists the users who hold the role and lets you add and remove them without leaving Continuum.
You can pick members while creating a role. Choose them on New Role, and one action creates the role and assigns them.
If the role's sync is not ready at that moment, the dialog stays open and continues in Edit mode for the role it just created, with your selection still pending and an explanation of why it did not close. Nothing is lost and nothing is created twice — the next Save applies the selection. The same applies if only some of the additions went through: the ones that failed stay pending and Save retries just those.
What the section holds depends on how your tenant signs people in. A native tenant names users; an SSO tenant maps identity-provider groups. The two are different fields, not two skins of one, and the section states which it is in its own subtitle — Users who hold this role. Changes apply when you save. against Identity-provider groups mapped to this role. Members receive it at their next sign-in.
| Native tenant | SSO tenant | |
|---|---|---|
| What it shows | The users who hold this role, as removable chips, with a count beside the heading | The identity-provider group names mapped to this role, as removable chips, counted the same way |
| Adding one | Type into the field to search the tenant's directory by name or email; the list shows each match's name with its email beneath. Someone who already holds the role is not offered again | Type the group name and either press Enter or use the Add group "…" action. There is nothing to search — see below |
| Removing one | Remove its chip | Remove its chip |
| When it takes effect | On Save, with the rest of the role | On Save. Members of a mapped group receive the role at their next sign-in |
| Where the data lives | In the Continuous identity system. Every read is live, and Continuum stores no member list, email address or identity mapping of its own | The same — Continuum stores no group mapping of its own |
Membership on the Administrator role is editable. It is the role's definition that is frozen — its permissions and scopes — not who holds it.
Removing a user signs them out of Continuous and of every Continuous solution, not only of Continuum. They can sign straight back in; what they lose is the session, and on signing back in they have whatever the remaining roles give them. The page warns you before you save, with a count of the users affected.
Removing a group mapping signs nobody out. Its members keep the session they are in and lose the role at their next sign-in, so the warning does not appear on an SSO tenant.
Removing yourself is confirmed before anything is written
Taking your own membership out of a role signs you out and may cost you the page you are on, so Save stops and asks first, naming the role: "You are removing yourself from … You will be signed out and may lose access to this page."
- OK resumes the save you interrupted, exactly as it was.
- Cancel abandons the whole save. Nothing is written, including the role's own permissions and scopes, and every edit stays as you left it — a save you deliberately backed out of should not be half applied.
The platform does not refuse this: handing your own role to someone else is a legitimate thing to do. The check is a confirmation, not a block. It compares against the signed-in user by identity and by email, and it applies on a native tenant only — a group mapping names nobody in particular.
On an SSO tenant, group names are not verified
Continuum cannot see your identity provider, so the group field has nothing to offer as suggestions — you type the name, and the popup holds only the add action and its hint. The field says so: "Group names are not checked against your identity provider."
That is worth taking literally. A misspelled group name is accepted, saved, and grants nobody anything, with no error to tell you. Copy the name from the identity provider rather than typing it from memory.
Two rules the field applies as you type:
- Names are compared case-insensitively, because the identity system compares them that way. Typing a case variant of a group already mapped is refused with Already mapped rather than creating a second mapping that collides on save.
- A group name is at most 200 characters when you add one. Names may legitimately contain spaces and slashes. A removal is sent back exactly as it was read, so a mapping already in place can always be removed regardless of its length.
A single save carries at most 100 membership changes, additions and removals counted together, as on a native tenant. You cannot re-case an existing mapping in one save — remove it and add the new spelling in two.
The role not active — sync roles failure belongs to native membership. On an SSO tenant a mapping write is not held up by the role's active state.
When the section is read-only, and why
The section always renders — it never quietly disappears — and states its own reason when it cannot be used. Each reason is a warning banner above the field, not a line of small print, and they are evaluated cause first, because each one is the reason the next cannot be judged:
| What you see | What to do |
|---|---|
| Member management requires the Continuous Auth integration, which is not configured for this environment. | The tenant has no identity integration. Nothing about membership is editable until it is configured — and this state shows the sentence with no field at all |
| Rename this role to manage its members — the name does not meet the Continuous Auth rule … Rename to 3-23 characters using only letters, digits, underscores or hyphens | The role's name doesn't conform, so it has no counterpart in the identity system to hold members. The banner states the rule outright so you can act on it here. There is deliberately no retry: a non-conforming name is left out of every sync, so retrying could not fix it |
| This role has not been synced to Continuous Auth yet — members can be managed once it has synced | Nothing to press. An attempt runs each time the role is opened or saved, at most once a minute after a failure, so re-opening the role is the retry. When the last sync failed, the banner also quotes the recorded reason — and if that reason asks for an action in the Continuous console, do it there first, because that case is not retried automatically. See Keeping roles in step with the identity system |
| Could not read members — … could not be read from Continuous Auth: … Reload the page to try again. | The identity system is configured but unreachable. The section reports the error and stays disabled rather than showing an empty role as the truth |
No member count is shown under any of these states. The role may well hold members in the identity system, and "0 members" beside "cannot be managed yet" would be a false claim.
A background refresh that fails after your member list has loaded leaves your edits alone. That matters after a partial save, below: the changes you need to retry are still there.
A save can apply some member changes and not others
The three parts of a role — its identity and permissions, its scopes, and its members — are saved as three separate writes, and members go last. So a save can succeed for the role and then fail for some of its member changes. When that happens the dialog stays open rather than closing, and tells you which is which:
- Some member changes failed. Each one is named — Add Jordan Reyes (jordan@…) — with the reason. The changes that landed are kept, and the failed ones stay pending, so Save again retries exactly those.
- The whole member apply failed. The role itself is saved; your member changes are still pending. Save again to retry them.
One reason worth recognising: role not active — sync roles. The identity system has withdrawn the role, so additions cannot be applied to it. Removals still run. Close and reopen the role — which retries the sync — then save again.
If the tenant's sign-in mode changed while the editor was open, the save is refused and tells you to reload. The editor pins the mode it loaded the chips against, so what you typed is never applied as the wrong kind of member — group names sent as user identities, or the reverse.
A "replace this person with that one" edit therefore never leaves the role empty in between. It also means a save that fails part-way is more likely to have added than removed.
One save carries at most 100 membership changes — additions and removals counted together. A larger change is refused with Too many membership changes in one request rather than partly applied; split it across saves.
Permission catalog
A permission is <objectType>.<action>.
- Actions:
view,create,edit,delete,execute. - Scope models:
- Workspace (W) — checked against the object's workspace (e.g. workflows, scripts, properties, thresholds, resources, service-requests, agents, agent-pools, connections, vision-card).
- Global (G) — tenant-wide (e.g. workspaces, frequencies, calendars, reports, custom-fields, tags, service-request-categories, script-catalog, settings, roles, audit-history).
- Workspace × Environment (WE) — both axes checked (e.g. workflow-instances, job-instances, workflow-deployments, service-request-deployments, self-service-portal).
- Implied view: granting
create/edit/delete/executeautomatically includes that object'sview("you can't manage what you can't see"). The one object type this does nothing for isscript-catalog, which has noviewof its own — see below.
service-request-categories covers the categories a self service button is filed in, and the
arrangement of the portal page — category order, band colour and button order. It is global, so
a role's workspace scope does not apply to it. Only Administrator starts with its create,
edit and delete permissions, because a category created from one workspace appears in every
workspace's picker. Roles that already held service-requests.view or service-requests.edit when
the object type arrived were given service-request-categories.view as well. That was a one-time
grant: add it yourself to a role created since.
Connections are checked, and the grant must be tenant-wide
A connection holds the credentials a job runs as — a batch user on an LSAM
machine, a database login, an MFT compression password. Those routes are now gated on the
connections permission for the action being taken, before anything is read or written:
| What you are doing | Permission needed |
|---|---|
| Listing connections, opening one, or Test | connections.view |
| Creating one | connections.create |
| Editing one | connections.edit |
| Deleting one | connections.delete |
Earlier builds authorized these on tenant membership alone, so anyone signed in to your tenant could list, create, rewrite or delete a connection — including changing the account a job runs as.
connections is listed as a workspace-scoped object type, but a connection carries no
workspace — connections belong to the tenant. So the grant has to be tenant-wide: a role whose
scope names particular workspaces holds the permission and still cannot use it, and the refusal says
the role's scope does not match rather than that the permission is missing.
Grant connections permissions on a role scoped to all workspaces.
A Builder who picks a batch user needs connections.view too. The job editor's connection
pickers read the same list, so a role without it shows an empty picker — which reads as "there are no
connections" rather than as a permission problem. Grant connections.view to any role that builds
jobs on legacy or database job types.
If the role service cannot be reached, the request is refused rather than allowed through. That is deliberate: a credential store is the wrong place to fail open.
script-catalog covers writes to the tenant's own script runners and script
types — create, edit and delete, and no view. Reading the
catalog stays on scripts.view, so anyone who can pick a runner on a job can already see it, and a
write route asks for scripts.view and the script-catalog action. Because there is no
script-catalog.view to imply, granting create, edit or delete adds no view permission of any
kind: a role needs scripts.view granted as well. It is global, so a role's workspace scope does
not narrow it — a runner belongs to the tenant rather than to a workspace. Administrator holds
all three. No other role was granted them when the object type arrived, so add them to any role that
should maintain the catalog.
What an event is refused for
An OpCon event is a command that changes something — holds a job, sets a threshold, writes a property.
Events are also checked against a role, when they are saved. The events a workflow or a Vision card carries run later under the platform's own identity, so the permission each event type needs is checked once against the person saving it, scoped to the workspace of the object the event names. A workflow or service-request event has no environment until it is deployed, so it is accepted if the role grants the permission in any environment of that workspace; a Vision action that names its target environment is checked in that one. Only the events a save introduces are checked, so withdrawing a permission later does not block an unrelated edit of a config that already exists.
The same check applies in these places:
| Where | Who is checked, and for what |
|---|---|
| An OpCon Event action on a notification trigger, or on an escalation policy level | The person saving it: the permission the event's type needs, in the workspace of the object it names and the action's environment. A test send is checked on the line as it will be sent. |
| The events edited onto a running job instance | The person editing them, for the events the edit adds or changes. |
| An event submitted to Continuum directly | The person submitting it. |
| A Self Service submission | The requester: self-service-portal.execute for the button, then every event the request sends — the permission its type needs, in the workspace of the object it names once the requester's values are filled in — and properties.view for every property it names. One refused event refuses the whole submission, and nothing is sent. |
Separately from any role, Continuum refuses an event in these cases, whoever submits it.
| Refused | Why |
|---|---|
| An event type that is not a real event type | An unknown type is never treated as allowed. |
| A self service button whose template's first field is not literally a real event type — including one that only becomes a real type once a placeholder is filled | The type has to be known when the button is saved. |
| A name that matches objects in more than one workspace | Continuum cannot tell which object the event means. |
A [[…]] token whose property name is itself assembled when the event runs | There is no way to know which property it would read. |
| At submit, a token that cannot be resolved, or an input placeholder left unfilled, in the name of the object the event acts on | The event would not name a real object. |
At submit, a $PROPERTY event on an SSI. or SJI. property with a schedule part | The parent workflow or container job it writes to is only known when the event runs. Leave the schedule part blank, or address the parent directly. See instance-scoped property events. |
A self service request whose value reads an encrypted property, or whose resolved text still contains a [[ or {{ opener | An encrypted value cannot be copied into an event, and text left unresolved would be expanded again. |
| A self service request whose built event line carries more tokens than its template wrote | If a requester's input assembles a token the author never wrote, nobody authorized that read. |
| A suffixed date token in a field read as a date | See Date and time tokens. |
Scope tuples
Each role scope is a (workspaceId, environmentId) pair where null = any:
| Scope | Applies |
|---|---|
(null, null) | Everywhere. |
(workspace, null) | That workspace, all environments. |
(null, environment) | That environment, all workspaces. |
(workspace, environment) | Only that combination. |
The object type's scope model decides which axes matter.
Where a grant has to be wider than one workspace
Most checks ask about the one workspace an object lives in. These ask for more, because the action itself reaches further than that:
| Action | What it needs |
|---|---|
| Creating an object | create on the workspace it is written into — not the one you started from. When the request names no workspace, that is the tenant's General workspace, so a role scoped only to workspace A cannot create an object that lands in General. |
| Moving an object to another workspace | edit on the destination, as well as the permission the edit itself needs. |
| Importing automation | create and edit on every workspace in the tenant, for each object type the bundle carries. An import matches existing objects by name across the whole tenant and writes them in place, so a role scoped to one workspace cannot import at all. |
| Exporting automation | view on every workspace in the tenant, for each object type the export asks for. |
| An environment-scoped transformation rule | workflow-deployments.edit and service-request-deployments.edit covering every workspace in that environment. The rule rewrites what is served to every deployment in the environment, so a grant for one workspace is not enough to write it. |
A report is a smaller case of the same thing. Without workspaces.view, a report still runs, but it
shows workspace ids where it would show names. Filtering or sorting that report on the
workspace name is refused outright, naming workspaces.view — a filter that silently matched
nothing, or an order by id that looked like an order by name, would be worse than a refusal.
Simulation and catalog views
Neither view has a link on the Roles list. Open them by address: /roles/simulation and
/roles/catalog.
- Permission simulation — pick a role (+ optional workspace/environment) and see each permission
as granted or denied, with a reason (
no_role_grants_action,no_role_scope_matches,missing_workspace_context,missing_environment_context). Use it to explain why a role does or does not grant something. - Permission catalog — a read-only, searchable list of every permission grouped by object type. The catalog currently holds 108 permissions across 29 object types. The newest is script-catalog (global), for maintaining the tenant's own script runners and script types; service-request-categories (global) covers the categories a self service button is filed in, and vision-card (workspace-scoped) arrived with the Vision feature.
- A role of your own named "Administrator" stops the built-in Administrator role from being created — a possible cause of unexpected Administrator behavior. Renaming or deleting your role is not enough on its own: the built-in role is created only after the platform next restarts, so contact support once you have renamed it.
- Use simulation to answer "does this role grant X?" questions.
Contact support when
- Simulation results contradict the permission catalog or the role's scopes. For Administrator specifically, check Administrator keeps up with the catalog first — a permission it was once short of is granted automatically now.