Users & Roles

Manage user accounts and decide what each person can do through the roles they hold.

Where

Admin › Identity & Access › Users & Roles

Licence feature

Access Control

Needs

role:read

Tabs

Seven, each shown by permission

The Users & Roles page (Admin → Identity & Access → Users & Roles) is where you manage user accounts and control what each person can do on the platform. It requires the access_control license feature and the role:read permission.

The page has seven tabs. Users is always shown; each other tab appears only when you hold the permission it needs:

Tab	Shown to holders of	What it is for
Users	-	User accounts, their status and their roles. See Users.
Members	role:read	Who is in this workspace, adding and removing people, and giving members roles. See Members.
Roles	role:read	The built-in roles, and custom roles (Advanced Access Control, Enterprise). See Roles.
Groups	group:read	Grant roles to many users at once (Advanced Access Control, Enterprise). See Groups.
Devices	agent:read	Wall displays paired to show an app. See Devices.
Ownership	workspace:read	Who receives a departing user's resources. See Ownership.
System Administrators	platform:grant_admin	Who holds the platform-wide System Administrator role. See System Administrators.

The page header has two help buttons: About these tabs explains each tab, and How roles work walks through the role model.

Users

User List

Open the Users tab to see every user account in the system.

Four overview cards appear at the top of the page:

Card	Description
Total Users	Total number of non-deleted user accounts
Administrators	Number of users with the System Administrator role
Active Users	Number of accounts with Active status
New This Week	Users created in the last seven days

Below the cards, a table lists all users with the following columns:

Column	Description
User	Avatar, full name, and email address
Roles	Assigned role badges
Status	Active, Inactive, or Deleted, plus a Review password badge on an account whose MaestroHub password needs an administrator's review (see Review password)
Created	Account creation date
Actions	Row action menu

Zoom

The Users tab: the page's seven tabs, the four summary cards and the user table

Search, Filters, and Sorting

Use the controls above the table to narrow down the user list:

• Search: Filter by name or email address in real time.
• Filters: opens Advanced Filters. Status shows All, Active, or Inactive users; Include Deleted set to Yes surfaces soft-deleted accounts alongside the others.
• Sort: Order the list by Name, Email, Created Date, or Last Login (ascending or descending).
• Table Settings: Customize column visibility, column order, column widths, and page size.

Zoom

Creating a New User

Click New User to open the creation form. The form is split into two columns: Basic Information on the left and Security & Access on the right.

Field	Type	Required	Description
First Name	Text	Yes	Minimum 2 characters. Accepts Unicode letters, spaces, dots, and hyphens.
Last Name	Text	No	Same character rules as First Name.
Email	Email	Yes	Must be a valid email format (max 254 characters). The system checks uniqueness in real time, so a duplicate email is rejected. Email cannot be changed after creation.
Password	Password	Yes	Minimum 8 characters. Must contain at least one uppercase letter, one lowercase letter, and one number. A strength indicator shows Weak / Fair / Good / Strong feedback as you type. Only shown when creating a user, not displayed when editing.

info

There is no role field on the create-user form. Assign roles with Manage Roles after the user has been created.

Editing a User

Click a user's name or select Edit from the row action menu to open the edit form. The same fields are shown with two differences:

• Email is displayed but disabled; it cannot be changed after creation.
• Password is not displayed. To set a new one, use Reset password (see Resetting a user's password).

The Security & Access column shows a Password row with a Reset password button (when you hold user:reset_password; disabled, with the reason, on your own account or one you may not reset), the user's Assigned Roles, and a Manage Roles button that opens the role-assignment dialog. Below them, it says how the account signs in: with single sign-on only, or with a MaestroHub password and who set it and when (an administrator by name, first-run setup, the admin CLI, or the user).

Review password

An account created by an identity provider (OIDC, SAML or LDAP) has no MaestroHub password, and its user cannot create one: only an administrator can set it. Before this was enforced, such a user could create a password themselves through Forgot password, and that password keeps working even after the identity provider disables them.

MaestroHub cannot tell who set a password that existed before the upgrade. When such a password is on an account that signs in through an identity provider, the Users list marks it Review password, and the edit form explains why.

To resolve it, reset the account's password as an administrator: Reset password in the user's row menu or edit form (see Resetting a user's password), or through the admin API (POST /api/v1/admin/users/{id}/reset-password) or the admin CLI. The new password is then recorded as yours, and the badge goes away.

• If an administrator gave the user that password, reset it and pass the new one to the user.
• If no administrator did, deactivate the account until you have spoken to the user. Resetting the password replaces the one you did not give, so it no longer signs anyone in.

The badge stays until an administrator resets the password. The user changing their own password does not clear it. A local account that is linked to an identity provider after the upgrade is not marked: its password was set while it was a local account.

Managing User Status

The row action menu on each user provides the following actions:

Action	Description
Edit	Open the user edit form
Manage Roles	Open the role-assignment dialog
Reset password	Set a new MaestroHub password for the user. See Resetting a user's password.
Activate / Deactivate	Toggle the user between Active and Inactive status
Select	Start selecting rows, to activate or deactivate several users at once. Shown to system administrators only.
View as <name>	See MaestroHub as this user sees it. See Viewing as another user.
Copy ID	Copy the user's ID to the clipboard
Delete	Delete the user account. It can be restored later.

Business Rules

• You cannot delete your own account.
• You cannot change your own status (activate/deactivate).
• Deactivating a user immediately invalidates all of their active sessions.
• Deleting a user invalidates all of their active sessions, revokes their personal access tokens and marks the account as Deleted.
• Deleting a user also withdraws their roles and shares, and hands the resources they own to the workspace's designated fallback owner (or, when none is set, to a workspace administrator, and failing that to a system administrator). A resource that can't be handed over waits in the adoption inbox. See Ownership.

Resetting a user's password

Reset password, in a user's row menu or in the Password row of their edit form, sets a new MaestroHub password for them. Use it when someone has forgotten their password and email reset is not available, or to give a password to an account created by single sign-on before granting it a platform role.

1. Open the user's row menu (⋯) and choose Reset password, or open the user and click Reset password in the Password row.
2. Enter the new password twice. It must meet the password requirements.
3. Click Reset password.

What happens:

• The user's password is replaced and their sign-ins end: any session they have open expires within the access-token lifetime (modules.auth.jwt.accessTokenDuration, 15 minutes by default), and they sign in again with the new password.
• Their personal access tokens are not affected and keep working. Only the user can revoke them, under Profile → Security; deactivating the account stops them too.
• They are not asked to choose another password at their next sign-in. Give them the password through a channel you trust, and ask them to change it under Profile → Security.
• The reset is recorded in the Audit Trail as user.password.reset_by_admin, with you as the actor. A refused or failed attempt is recorded too, with its reason. User accounts are platform-wide, so these records are under the Audit Trail's Platform view, not This workspace.

Who sees it:

• Who can use it: holders of the user:reset_password permission: the Identity Administrator, Security Administrator and System Administrator roles. It is not shown to anyone else.
• It is disabled on a user whose platform role holds more than yours (an Identity Administrator cannot reset a Security or System Administrator's password), with the reason: only an administrator who holds everything that role grants can.
• On your own row it is disabled: change your own password under Profile → Security, where you confirm your current one. If your account signs in only with single sign-on, your password is managed by your identity provider; for a MaestroHub password, ask another administrator to set one.
• Deleted users have no row menu actions other than Restore.

The same reset is available as POST /api/v1/admin/users/{id}/reset-password with {"new_password": "…"}, and, without a running server, with the admin CLI.

Viewing as another user

View as <name> opens a session in which you see MaestroHub exactly as that user does: their pages, their data and their permissions. Use it to check what someone can reach before or after you change their roles.

• Who can use it: holders of the user:impersonate permission: the Identity Administrator, Security Administrator and System Administrator roles. The action is shown only for Active users. An Identity or Security Administrator cannot view as a user whose platform role holds more than theirs (an Identity Administrator cannot view as a Security or System Administrator).
• What you can do: the session is read-only. Any change, such as saving or deleting something, is refused.
• Limits: you cannot view as yourself or as a system administrator, and you can have only one session at a time. A session ends after 60 minutes.
• While it runs: a banner at the top of every page reads Viewing as <name>, with a read-only badge and the minutes left. Click Exit to return to your own account.
• Audit: starting and ending a session are recorded in the audit trail (impersonation.started and impersonation.ended), and every audited action taken during the session records you as the impersonator. See Audit Trail.

Restoring Deleted Users

Deleted users can be brought back:

1. Open Filters in the user list and set Include Deleted to Yes.
2. Find the deleted user; they appear with a Deleted status badge.
3. Select Restore from the row action menu.

Restored users return with Active status and all their previous profile details intact. Their access does not come back: the roles and shares withdrawn at deletion, and the resources handed to someone else, stay where they are. A dialog lists them after the restore, so you can grant the roles again or transfer resources back.

---

Roles

Overview

The Roles tab lists the built-in role catalog and your workspace's custom roles. It is shown to holders of role:read.

Licensing

Role-Based Access Control requires the access_control license feature. The advanced_access_control feature (Advanced Access Control, in the Enterprise edition and the free trial; not in Foundation) unlocks the extended catalog and the governance capabilities listed below. (Licenses issued with the older basic_rbac / enterprise_rbac feature names continue to work; they resolve to the current names automatically.) SSO-based role mapping additionally requires an active SSO license feature.

RBAC has three levels:

RBAC Level	Behavior
None	RBAC is disabled. All authenticated users have unrestricted access to every feature. Reserved for community builds.
Basic (access_control)	The ten persona roles below. Every API request is checked against the caller's role permissions.
Advanced (advanced_access_control), Enterprise	Adds the granular feature roles, custom roles, groups, and the governance capabilities listed below: relationship-based access control (per-topic and per-branch grants that follow your namespace tree) and attribute-based controls (time-bound grants; time-window and group-scoped conditions, applied by stewards through the deny and approval flows).

Persona Roles (Basic)

Basic RBAC is persona-based: you assign people a role that matches their job, and each persona carries a fixed, pre-composed permission set.

User accounts are platform-wide. One account can be a member of several workspaces, so creating, editing, suspending, deleting and resetting accounts, configuring single sign-on, and adding people to workspaces belong to the platform roles (System, Identity and Security Administrator). A Workspace Administrator gives the members of their workspace their roles, and can remove members. See Members.

Role	Display Name	Description
System.Admin	System Administrator	Unrestricted access to everything, across every workspace. The only role that can read deployment logs and manage the license.
Workspace.Admin	Workspace Administrator	Full operational control inside their workspace (connections, pipelines, topics, dashboards), plus reading the workspace's audit log, and managing the workspace's own roles, groups, agents and API clients. Does not manage user accounts or single sign-on, which are platform-wide (see Identity Administrator).
Workspace.Member	Member	The lightweight default: read the common surface, create own dashboards, subscribe to UNS data, read the workspace's libraries and the meaning of the topics they can read. Cannot publish, build, give meanings, or manage anything shared.
Identity.Admin	Identity Administrator	A platform role: manages user accounts and single sign-on across the platform, and every workspace's roles, groups, agents and API clients. Cannot act on an account that holds more power than its own (such as a System Administrator). Granted under Identity & Access → System Administrators.
Security.Admin	Security Administrator	A platform role: identity administration plus audit-log read and export across the platform, the governance counterpart to Identity Administrator. Granted under Identity & Access → System Administrators.
Persona.DataEngineer	Data Engineer	Builds the platform end-to-end: connections, functions, pipelines, topics, dashboards.
Persona.PlantOperator	Plant Operator	Operates what engineers built: runs pipelines, tests connections, publishes data. On the plant model, records what happens to the machines (rejects, lab results, fills, changeovers) and declares their state (maintenance, changeover, stopped), both at once, and proposes corrections to what a machine is, which an engineer decides.
Persona.Analyst	Analyst	Read-and-analyze: browses data, builds own dashboards.
Data.StreamViewer	Data Stream Viewer	Read-only live access to UNS topics: subscribe and read history, publish nothing. Intended for read-only MQTT consumers.
Workspace.Display	Display	Read-only identity for a paired display: opens published apps and shows live data and dashboards. Display pairing assigns it.

Features that create an identity for a purpose (a paired display, the MQTT broker credential, an i3X app) ask MaestroHub for the narrowest roles your licence offers for the permissions they need, instead of naming a role, and show which roles they granted. GET /api/v1/authz/roles/resolve answers the same question for your own tools.

Advanced Catalog

advanced_access_control adds four more personas and the granular feature roles, for a total of 27 built-in roles:

Personas: Compliance.Auditor (Compliance Auditor, pure read-side auditing, separated from identity administration), and the Fleet triad (Fleet.Admin / Fleet.Editor / Fleet.Viewer) on Fleet Manager deployments.

Feature roles follow an Admin / Editor / Viewer pattern per feature area, for composing access finer than a job title:

Area	Roles	Scope
Connect	Connect Admin, Connect Editor, Connect Viewer, Connect Read Executor	Connections and functions
Automate	Automate Admin, Automate Editor, Automate Viewer	Pipelines
Data	Data Admin, Data Editor, Data Viewer	UNS topics, dashboards, and recording and declaring on the plant model
Apps	Apps Admin, Apps Editor, Apps Viewer	App Studio apps (App Studio is in release 3.0 as Beta, a paid add-on)

Admin = full control of the area. Editor = view plus runtime actions (run, test, publish) without create/edit/delete. Viewer = read-only. Connect Read Executor = execute read-effect functions only.

What Advanced Access Control unlocks beyond roles

How each part works, with the plant's examples, is in the Advanced Access Control section.

The extended catalog is only part of the feature. Advanced Access Control also enables:

• UNS topic-level authoring. Role permissions are enforced on every API request and on the UNS data plane on both tiers, and any per-topic grant or deny that exists is always honored, so changing the license never widens access. What Advanced unlocks is creating per-topic governance: topic sharing, subtree grants, and per-topic permissions on the broker and historian paths. On Basic none of these objects can be authored, so in practice access is governed by roles alone.
• Custom roles: admin-assembled permission bundles. A custom role granting function execution can narrow it to specific operation effects (read, stream, discover, write, delete, invoke), e.g. a "PLC Read-Only Operator" that browses tags and tails streams but can never write, delete, or invoke arbitrary code. The built-in Connect.ReadExecutor ships this shape ready-made for the observational triple.
• Groups: sets of users (and of other groups) that hold roles together.
• Sharing governance: topic stewardship, deny rules, and the request-access → approve workflow.
• Time-bound grants: shares, role assignments, and group memberships with an expiry. On Basic new ones are refused; grants that already carry an expiry still end on schedule, because the expiry sweeper runs on every licence. Renewing one is a fresh decision to give the access, so only someone who could grant it now may renew it: share on the resource for a share or an approved access request, assigning the role for a role, adding members for a group membership. The person who holds the grant does not extend it themselves, and someone who granted it but has since lost that right does not either. My Access → Expiring shows, on each grant, whether you may renew it and, if not, whom to ask.
• Cloning needs read: a pipeline, connection, function, app or dashboard is cloned only by someone who may read it, whatever their role grants for cloning. A copy carries the original's configuration.
• Per-resource ownership enforcement: "creators manage what they created" checks on individual resources.

Upgrading from 2.6.x: what changes for access control

Access control is enforced the same way after the upgrade; what changes is where ownership applies, what a few reads answer and what stays open after a revoke.

• Resource ownership carries over; there is nothing to run afterwards. context-platform upgrade apply keeps each resource's owner and records the workspace the resource belongs to. On 2.6 an owner's rights on a resource applied in every workspace; on 3.0 they apply in the resource's own workspace only. A resource whose 2.6 owner was 2.6's placeholder for "creator unknown" is owned by the system afterwards and waits on the Ownership tab for an administrator to give it an owner. An ownership the upgrade cannot place (the resource is gone, or no workspace can be found for it) is dropped, and the upgrade report names the resource and its old owner. See Upgrade from 2.6.x to 3.0 and Ownership.
• Members no longer see the user list. user:read is not part of the Workspace.Member baseline any more; pickers show display names without it. Where a team needs the directory, assign a role that carries user:read.
• Reads answer for the workspace you are acting in. A role's holders, a user's permissions and roles, a permission's holders and a subject's effective permissions are scoped to the workspace of the request. A platform administrator may ask for platform scope (domain=*); anyone else asking for another workspace is refused. The adoption queue (orphaned and unclaimed resources) requires workspace:update.
• Revocation reaches what is already open. A revoked personal access token, a suspended agent, a disabled OAuth2 client and a denied browser stream are refused on their next request rather than when a cache expires. A live browser stream stops within about a second: modules.uns.config.wsRevocationFastPath is on by default (set it to false to fall back to the wsRevocationSLA bound, 60 seconds). Open browser tabs refresh their permission map on their own when a role, share, deny or group changes; a revoked control disappears without a reload.
• Custom roles keep their parents by identity, not by name. A parent role deleted and re-created under the same name is a different role: children that pointed at the old one do not inherit from the new one until you edit them and declare it. Deleting a parent that other roles depend on is refused unless you force it, and force prunes the reference from the children.
• Secrets are write-only, for every role. The secret:* verbs a 2.6.x Data Engineer held (secret:read, secret:update) no longer exist: no endpoint ever checked them, and the vocabulary was removed with the 2026-Q3 consolidation. A stored credential is rotated by updating its connection (connection:update) and is returned masked on every read: nobody, the platform administrator included, can reveal one through the API. The upgrade rehearsal lists this as a decision that flips; it is a dead verb disappearing, not a capability the persona loses.
• Split (Enterprise) deployments. The standalone WebSocket service runs the same revocation fast path as the single binary: a revoke on any replica purges its delivery gate within about a second and open tabs receive permissions.changed. Its unsRevocationSLA (the safety-net bound) defaults to 60 seconds and unsRevocationFastPath to on; the service's health payload reports the path under revocationFastPath: live with the replica id, or the reason it is not.

Viewing Roles

Open the Roles tab to see the role list. An Available Roles card shows how many roles your license lets you assign, out of the whole catalog, and a search bar filters the list by name.

Each row shows the role's display name, its name and its description. Feature roles carry a level badge (Admin, Editor or Viewer). Roles that require Advanced Access Control are listed last with an Enterprise lock badge when your license does not include it.

Click a role to open its detail view, which shows:

• Header: Display name, name, level badge and description.
• Permissions: Grouped by entity, showing which actions are granted.
• Users with this Role: The users who currently hold this role.

Creating Custom Roles

Custom roles are part of Advanced Access Control, an Enterprise feature.

With Advanced Access Control and the role:create permission, a Create role button appears above the role list. Each row's menu also offers Duplicate as custom, which starts a new custom role from that role's permissions. Built-in roles can't be edited or deleted; custom roles can. See Custom Roles.

Assigning Roles to Users

Roles are given to members of the workspace only. A person who is not a member is refused with Not a member of this workspace; add them on the Members tab (or Users → Workspaces) first.

You can access the Manage User Roles dialog in three ways:

• Select Manage roles from a member's action menu on the Members tab.
• Click Manage Roles in the user edit form (under Assigned Roles).
• Select Manage Roles from the row action menu in the user list.

When the person is not a member of the workspace you are in, the dialog says so and the role picker is disabled. A platform identity administrator sees Add <name> to <workspace> there, which adds them in one click.

The dialog shows:

• User info: The user's name at the top.
• Add Role: A dropdown to select and assign a new role. It lists the roles your license makes available and the user does not hold yet. Roles that can't be granted inside a workspace are listed but disabled, with the reason: System Administrator is granted on the System Administrators tab.
• Current Roles: The user's roles, each with the date it was assigned. With Advanced Access Control (Enterprise), a role the user receives through a group carries a via <group> badge.
• Groups: The groups the user belongs to.

Each role entry has a Remove button to unassign it from the user. A role the user holds only through a group can't be removed here: remove it from the group, or the user from the group, on the Groups tab.

---

Members

A person is a member of a workspace by a record of its own: being a member is what lets them enter the workspace, and their roles there decide what they can do in it. A member without a role can enter the workspace and reads its semantic libraries, which every member reads unless a deny rule takes one away; they see nothing else in it.

• New accounts become members of the workspace they are created in (or the one their single sign-on provider places them in), and get the workspace's default role.
• A person you add joins as a Workspace Member. They get the Workspace Member role in that workspace; any further roles are given separately, by whoever may give roles in that workspace. Someone who is already a member keeps the roles they hold.
• Taking away someone's Workspace Member role takes their access to the workspace, so it needs what removing them from the workspace needs: workspace:update there (the workspace's administrator) or user:revoke (a platform administrator). A feature administrator who manages roles can't do it. To take someone out of the workspace, remove them on the Members tab.
• A membership can end on a date you choose when adding the person. When it ends, they leave the workspace exactly as if they had been removed.
• Removing a person from a workspace takes with it every role, group membership and share they had there; what they own in it is handed over as when an account is deleted (see Ownership). Their account, and their memberships of other workspaces, are untouched.
• A platform role reaches workspaces without a membership when its permissions apply in workspaces (System, Identity and Security Administrator). Fleet roles are not held here at all: they belong to Fleet Manager, on the fleet hub.

The Members tab

The Members tab (shown to holders of role:read) lists the members of the workspace you are in: name, How added (account created here, single sign-on, added by an administrator, carried over on upgrade), Member since and Member until.

Action	Who can do it
Add people	Platform identity administrators (user:assign: System, Identity and Security Administrator). Pick people, optionally set Member until, then Give roles to each person added.
Manage roles	Anyone who can see the tab opens the role dialog; giving and removing roles needs role:assign / role:revoke.
Remove from workspace	The workspace's administrator (workspace:update in the workspace, held by the Workspace Administrator), for members all of whose roles they could give; or a platform identity administrator (user:revoke), for anyone except an account holding a role above a workspace they do not hold themselves.

A Workspace Administrator does not see Add people: bringing people into a workspace is a platform identity administrator's.

Remove is offered per member only when you may remove them. When you can't (the member is the last Workspace Administrator, holds a role you could not give, or you hold neither removal permission), Remove is greyed out and says why. Removing several people at once removes only the ones you may remove; the confirmation says how many were left out and why.

Adding can be refused for a person, with the reason, and nothing is written for them:

• there is no account with this id: the account was deleted, or never created;
• their earlier removal from this workspace has not finished: when they were removed, taking away what they held there did not complete; it is retried automatically every few minutes, and adding them again works once it has;
• an end date on a person who holds a role above a workspace you do not hold yourself, by the same rule as removing them.

Who else reaches the workspace. People holding a platform role whose permissions apply in workspaces (System, Identity and Security Administrator) reach every workspace without being members. Below the members, a platform identity administrator sees them by name with their roles; anyone else sees one line, such as 3 platform administrators also reach this workspace, saying they are managed under Identity & Access → System Administrators. Nothing is shown when there are none.

The last Workspace Administrator stays. A Workspace Administrator can't remove a member, revoke Workspace Administrator, remove someone from a group, delete a group or change a custom role when that would leave the workspace without a Workspace Administrator. The refusal says so; a platform administrator can still make the change.

Removing several people at once reports each person's outcome; a person the change was refused for, or failed for (nothing changed for them), is named with the reason and not counted as removed.

A person's workspaces

Platform identity administrators see a person's memberships from the Users tab: open the row's action menu and choose Workspaces. It lists every workspace the person is a member of, how and when they were added and until when, and lets you:

• Add to a workspace they are not in, with an optional end date;
• Remove them from one, after a confirmation saying what goes with it. As on the Members tab, Remove is greyed out with the reason where you may not remove them.

---

Groups

A group collects users so you can grant roles once: every member inherits every role the group holds. Members are added by hand: SSO role mapping assigns roles, not group membership.

The Groups tab is shown to holders of group:read. Groups are part of Advanced Access Control, an Enterprise feature. Groups require the advanced_access_control license feature; without it, the tab explains what the feature adds. See Groups.

Devices

The Devices tab pairs wall displays (screens that show an App Studio app; App Studio is in release 3.0 as Beta, a paid add-on) and is shown to holders of agent:read. Each paired display gets its own read-only identity, not a user's login.

To pair a display:

1. On the screen, open /pair. It shows an 8-character code.
2. On the Devices tab, click Pair a display (needs agent:create).
3. Enter the Code on the screen, a Display name, the App to show, and the Roles the display holds. Only read-only roles can be bound to a display.
4. Click Approve, or Deny to refuse the screen.

The table lists each display with its status, the app it opens, its roles, when it was paired, when it was last seen and when its token expires. A display's token lasts a year by default. Revoke a display (needs agent:update) to end its token and identity at once: its screen returns to the pairing page on its next request.

Ownership

Every resource a person creates (a connection, a pipeline, a dashboard) has an owner. The Ownership tab (shown to holders of workspace:read) decides what happens to a user's resources when the user is deleted:

• Designated fallback owner: the user who receives a departing user's resources in this workspace.
• Adoption inbox: resources that could not be handed over, waiting for an administrator to give them a new owner.
• A table of resources that have no reachable owner, for example resources owned by the system after an upgrade.

Set a fallback owner before you delete anyone. See Ownership.

System Administrators

The System Administrators tab lists who holds the platform-wide System Administrator role (System.Admin), grants it with Grant System.Admin and revokes it. It is the only place this role is granted: the Manage Roles dialog and SSO role mapping can't assign it. Only system administrators see this tab. See System Administrators.