Skip to content

Edit, suspend, reactivate or remove a workload

Rename a workload, stop it temporarily while it is in doubt, let it sign in again, or revoke it for good.

Who can do it

A tenant administrator, or a platform super admin working inside the tenant on a private-cloud or on-premise deployment. On a SaaS deployment the platform refuses a platform administrator's changes to a tenant's workloads.

Edit, Suspend and Reactivate need the permission to update workloads; Revoke workload needs the permission to revoke workloads. The console shows each control only with its permission, and none on a workload that is already revoked. A workload never changes itself.

Before you start

  • Renaming and reactivating a workload require you to hold every scope the workload holds.
  • Revoking cannot be undone. When you only need to stop the workload for a while, suspend it.

Steps

  1. Open Administrative Workloads and select the workload's name. The controls are beside its status.
  2. To change its name or description, select Edit, change Name or Description, and select Save. The keys, federated identities, scopes and status do not change.
  3. To stop it obtaining tokens, select Suspend on an Active workload, enter a Reason, and select Suspend workload.
  4. To let a suspended workload sign in again, select Reactivate and then Reactivate workload.
  5. To remove it for good, select Revoke workload, type the workload's name to confirm, enter a Reason, and select Revoke.

What you see when it worked

  • Edit: "Workload updated." The new name is the one the audit trail records from the workload's next token on.
  • Suspend: "{name} suspended: its tokens are refused until it is reactivated." Its status is Suspended; its keys, federated identities and scopes are kept, and every token it holds is refused at once.
  • Reactivate: "{name} reactivated." Its status is Active, and its keys and federated identities sign it in again. Tokens refused by the suspension stay refused.
  • Revoke: "{name} revoked." Its status is Revoked. Every key and federated identity is revoked with it and its tokens are refused at once. The record stays for the audit trail, and its name becomes free for a new workload.

Every change, with its reason, is recorded in the audit trail.

If it fails

What you see Cause What to do
"A live administrative workload of this tenant already uses this name. Choose another name, or revoke the workload that holds it." Another workload of the tenant that is not revoked already uses the new name Choose another name
The name is rejected It has characters other than letters, digits, dots, hyphens and underscores, or does not start with a letter or digit Correct the name
"Refused by the subset rule:", followed by the scopes you do not hold You do not hold every scope the workload holds Ask an administrator who holds them
"An administrative workload cannot change its own status, credentials, federation bindings or scopes." The request was made by the workload itself A person makes the change
"The administrative workload is revoked, which is terminal. Register a new workload instead." The workload is revoked, which is final Create a new workload
"Does not match. Type it exactly as shown, including capitalization." The typed name differs from the workload's Type the name exactly as shown

Without the console

Surface How
API PATCH /api/v3/admin/tenants/{tenantId}/workloads/{workloadId} (operation updateTenantWorkload), a JSON Merge Patch of name and description
API POST /api/v3/admin/tenants/{tenantId}/workloads/{workloadId}/suspend (operation suspendTenantWorkload)
API POST /api/v3/admin/tenants/{tenantId}/workloads/{workloadId}/reactivate (operation reactivateTenantWorkload)
API POST /api/v3/admin/tenants/{tenantId}/workloads/{workloadId}/revoke (operation revokeTenantWorkload)