Manage roles and permissions
This feature is still being finalized by Development.
Roles define what people can do, and scopes define where they can do it. You assign a set of permissions to a role and then scope the role to the workspaces and environments it applies in.
Roles decide which screens a person can open. In design and administration areas — workflows, scripts, the Toolkit, service requests and Self Service, Vision cards, notifications, roles, workspaces and custom fields — they also decide every action, and lists show only what the role's scopes reach.
On Processes, Agents, agent pools and plugins, the Event Log, saved reports, Vision's live view and Environments, a role decides only whether the screen is offered. Anyone signed in to your tenant can use the actions there, so do not rely on roles to restrict them.
Connections are no longer in that list. Every action on a
connection — listing, opening, Test, create, edit and delete —
now needs the matching connections permission. Because a connection carries no workspace, that
grant has to be on a role scoped to all workspaces: a role confined to particular workspaces
holds the permission and still cannot use it. Grant connections.view to any role that builds jobs
on legacy or database job types as well, or its connection pickers come up empty. See
Connections are tenant-wide.
Permission checks used to let every signed-in request through, so review your roles: an account that worked only because nothing was being checked now needs the grant in the areas that are checked. See What roles control today.
Everyone either has too much access or waits on an administrator for everything. Without scoped roles there's no way to prove who can do what, and where, when an audit asks.
Roles
A role has a name, a set of permissions, and one or more scopes. The built-in Administrator role has every permission everywhere and can't be changed. You can create roles, duplicate an existing one as a starting point, and edit or remove the roles you create.
"Every permission" includes permissions added after your tenant was created — the role is topped up automatically after an upgrade, and nothing it already holds is taken away. On an older tenant this did not always hold, and the newest permissions really could be missing from Administrator with no way to add them by hand. If you have a note somewhere to check that after an upgrade, you can drop it. See Administrator keeps up with the catalog.
Where you create and edit one
Everything happens on the Roles list. New Role opens an editor dialog over the list; hovering a row reveals a ⋮ menu with Edit, Duplicate and Delete; double-clicking a row opens it. There is no separate role page to open and come back from, and Delete is unavailable on the built-in Administrator role because the platform refuses to delete one.
The dialog keeps Name and Description in view at the top and puts the rest behind a two-way switch:
- Privileges — the permission matrix and the scopes. The matrix is one table with the scope tiers as grouped rows under a header that stays put while you scroll, so a given action's checkboxes line up down the column.
- Members — who holds the role, and the event identities that carry it.
Save stays disabled until something has actually changed, and closing with unsaved changes asks first. Because the dialog is addressed by the URL, a link to a role still opens it and Back closes it rather than leaving the page.
Naming a role
A role name must be 3 to 23 characters using only letters, digits, underscores and hyphens — no spaces. The name is what the role is called in the Continuous identity system too, which is what lets it hold members there, so the rule is stricter than for workspaces or environments.
An older role with a name like Workflow Designer keeps working exactly as it did — it grants
the same access to the same people. But its name field is in error the moment you open it, and the
role can't be saved again until you rename it. It is also left out of the sync below until then.
Rename those roles deliberately rather than hitting it mid-edit. Duplicate does the conversion
for you as a starting point: duplicating Workflow Designer opens on Workflow_Designer_copy.
Keep roles in step with the identity system
Creating, renaming, deleting or duplicating a role sends the tenant's whole set of roles to the Continuous identity system, so a role defined here is the role members are assigned to there. Editing only a role's permissions, scopes or description doesn't need to — the identity system holds none of those.
Where the integration is configured, the Roles list shows when the last sync happened, or why it failed. There is nothing to press — the line reports, and the platform retries by itself.
A failed sync never blocks the change that triggered it: the role is created or renamed regardless, and the failure is recorded. The retry then runs when the thing that needs it is read — the list's status retries the tenant, and opening a role or reading its members retries that role — before the read returns, so what you are shown already reflects it. It only runs while something is unhealthy, not again within a minute of a failure, only when the person reading may edit roles, and only once your tenant has synced successfully at least once.
So if a role you created isn't showing up on the identity side, open it while signed in with
roles.edit. That is the retry. If your tenant has never synced successfully, the next role create,
rename, delete or duplicate tries again instead.
A tenant with more than 100 roles is not synced at all, and the list reports more than 100 roles — delete roles you no longer need.
A role whose name doesn't conform is left out of every sync, so no retry helps — rename it. And when the recorded reason asks you to do something in the Continuous console, do that first: that case isn't retried automatically, and the next role create, rename or delete clears the reason, which would hide the thing you still have to fix.
Membership on the identity side is held against the role's name, so a rename re-assigns every holder under the new name and withdraws them from the old. On a native tenant that signs each of them out once; on an SSO tenant a group mapping is moved and nobody is signed out. Changing only the capitalization moves nobody.
The role editor warns you before Save, naming how many members will move. Expect it to take a while for a large role — the rename waits for the move, and a thousand members can mean several minutes with the tenant's other syncs queued behind it. While it runs, the Roles list says a rename is moving its members; that is progress, not a failure.
If a move stops part-way, the next sync finishes it — including the retry that runs when you open the role — and the old name stays reserved until it does. Don't create a role under that old name until you've checked the identity side. See Renaming a synced role moves its members with it.
The delete confirmation tells you that access granted by the role is withdrawn at each member's next sign-in, before asking you to confirm. Deleting is owned by the Roles list wherever you start it — the editor's Delete hands the role back to it — so there is one confirmation to read, not two. After a delete the sync status is re-read, so a withdrawal the identity system refused shows up on the list straight away instead of at your next visit.
The Roles list also offers Event Identities, for the machine identities that submit events into the platform rather than for people. Management of those identities is switched off, so the section reports "Event identity management is not switched on in this environment" — expected, and nothing to raise. To register an identity for an agent, follow Agent-raised events.
A role's Members section lists the event identities that hold that role, read-only, each linking to its own page. Reading that list works whatever the role's sync status. Giving an identity a role is done from the identity, not from the role.
Add and remove a role's members
You do this in the role editor's Members section, while creating the role or later. When you create a role, one save creates it and assigns its members. If the role's sync isn't ready at that moment, the dialog stays open and continues in Edit on the role it just created, with your selection still pending and the reason on screen — save again to apply it. Nothing is created twice.
What you name here depends on how your tenant signs people in. On a native tenant you name users. On an SSO tenant you map your identity provider's group names — which you can now do here, rather than only in the identity system.
To change who holds a role on a native tenant, complete the following steps:
- Open the role from the Roles list — Edit on its ⋮ menu, or double-click the row.
- Switch to Members and review the users listed. The count sits beside the heading.
- To add someone, type into the field and search the directory by name or email, then pick them from the list. Someone who already holds the role isn't offered again.
- To remove someone, remove their chip.
- Select Save. Nothing is applied until you do.
On an SSO tenant, the same section holds Groups instead:
- Open the role from the Roles list.
- Switch to Members and review the mapped group names.
- To map a group, type its name and press Enter, or use the Add group "…" action in the popup. There is nothing to search — Continuum cannot see your identity provider.
- To unmap a group, remove its chip.
- Select Save. The people in a mapped group receive the role at their next sign-in.
Group names are not checked against your identity provider, so a misspelling is accepted, saved, and grants nobody anything — with nothing to tell you. Names are matched without regard to case, so a case variant of a group already mapped is refused as Already mapped rather than mapped twice.
You can change the Administrator role's members. It's that role's permissions and scopes that are fixed, not who holds it.
Removing a user from a role signs them out of Continuous and of every Continuous solution, not just OpCon Continuum. They can sign back in immediately, with whatever their remaining roles give them. The editor tells you how many users a save will sign out before you commit it.
Unmapping a group signs nobody out — its members lose the role at their next sign-in instead.
If your own membership is among the removals, Save asks before writing anything: you will be signed out and may lose the page you are on. OK carries on with the save as it stood. Cancel abandons the entire save — permissions and scopes included — and leaves every edit where it was.
The platform doesn't stop you: handing your role to someone else is legitimate. It just won't let you do it by accident.
The section always shows, and each reason is its own warning banner: the tenant has no identity integration configured (in which case there is no field at all); the role's name doesn't conform, and the banner states the rule so you can rename it without looking it up; the role hasn't synced yet, in which case there is nothing to press — an attempt runs each time you open or save the role, and the banner quotes the recorded reason when the last sync failed; or the identity system couldn't be reached, in which case reload to retry.
No member count is shown in any of these states. The role may hold members in the identity system, so "0 members" would be a false claim rather than a blank.
A role's identity and permissions, its scopes, and its members are three separate writes, and members go last. If some member changes fail, the dialog stays open, names each failure with its reason, and leaves those changes pending so Save retries exactly them. One reason to recognise: role not active — sync roles means the identity system has withdrawn the role — close and reopen the role, which retries the sync, then save again.
Additions are applied before removals, so a "swap this person for that one" edit never empties the role in between. One save carries at most 100 member changes, additions and removals counted together; a bigger change is refused with Too many membership changes in one request, so split it.
If the tenant's sign-in mode changed while you had the editor open, the save is refused and asks you to reload, rather than applying what you typed as the wrong kind of member.
Permissions
A permission is an action on an object type: view, create, edit, delete, or
execute. Object types fall into scope models:
- Workspace: things that live in a workspace (workflows, scripts, properties, thresholds, resources, service requests, agents, agent pools, connections).
- Global: tenant-wide settings (workspaces, frequencies, calendars, reports, custom fields, tags, the script runner and script type catalog, roles, audit history, and more).
- Workspace + environment: runtime things (workflow and job instances, deployments, the self-service portal).
Granting create, edit, delete, or execute automatically includes view for that object —
you can't manage what you can't see.
One object type is the exception, because it has no view of its own: script-catalog, which
covers maintaining the tenant's own script runners and script types.
Those are read under scripts.view, so a role that maintains them needs scripts.view granted as
well — its create, edit and delete imply nothing.
Scopes
Scope a role to a workspace, an environment, both, or leave either open to mean "any":
| Scope | Applies |
|---|---|
| Any workspace, any environment | Everywhere |
| A workspace, any environment | That workspace |
| Any workspace, an environment | That environment |
| A workspace and an environment | Just that combination |
Configure a role
To set up a role, complete the following steps:
- Go to Roles and add a role (or duplicate one).
- Enter a name — 3 to 23 characters of letters, digits, underscores or hyphens.
- Select the permissions the role should grant.
- Set the scopes: the workspace/environment combinations where it applies.
- Optionally, switch to Members and choose who holds the role — see Add and remove a role's members.
- Save.
Check what a role grants
Use permission simulation: choose a role (and optionally a workspace and environment) to see each permission as granted or denied, with the reason. It's the quickest way to confirm a role does what you intend. The permission catalog lists every available permission, grouped by object type.
Neither has a link on the Roles list — open them by address, at /roles/simulation and
/roles/catalog.
An event whose type is not real, or that names an object Continuum cannot pin to one workspace, is refused for everyone. See What an event is refused for.
Related topics
- Roles and permissions — full configuration reference and troubleshooting
- Manage workspaces (Administrator)
- Manage environments (Administrator)