opschain admin users reassign-automations
Included from Basic tier
opschain admin users reassign-automations <username> --to <service-account> [--provider <auth_provider>]
The offboarding repair verb: repoints every
standing automation the user's identity executes — triggers and scheduled
activities naming them run_as, plus ones they created with no explicit
run_as — onto a service account, in one set-based write (v2
UserService.ReassignAutomations, admin-gated on the step-up floor). It is
also the handover path when a personal automation outgrows its owner. In
the GUI the same sweep is Reassign automations… on a disabled row of
Administration → Users; its target picker offers enabled service accounts
only.
Semantics worth knowing:
- Only the executing identity moves. Authorship (
created_by) stays historical on every row; the automation'srun_asnow names the service account, and its firings execute — and authorisation-check — as that principal. - The target must be an enabled service account (
opschain admin service-accounts): reassigning onto a human recreates the offboarding landmine, onto a disabled account the stranding — both are named refusals. The service account needs its own authority on the affected projects (policy assignment or group membership) for the firings to pass RBAC. - Idempotent: a second run moves nothing. After a reassign,
admin users disable <username>no longer warns about these automations — nothing executes as the leaver any more. - An automation the user created but someone else already runs as is left untouched (it never depended on this identity).
opschain admin users reassign-automations carol --to deploy-bot
Reassigned carol's automations to service account deploy-bot:
triggers (2): bot-run, nightly-deploy
scheduled activities (1): deploy (/projects/demo)
-o json|yaml prints the reassignment summary (exact counts; each name
list caps at 20 entries).
Flags
| Flag | Meaning |
|---|---|
--to <service-account> | The service account the automations execute as from now on (required). |
--provider <auth_provider> | Select the identity provider's row (local, ldap:<key>, oidc:<key>, …) when the username exists under more than one. |
--server <url> | Server base URL (default: the active context / OPSCHAIN_SERVER). |
--auth-token <token> | Admin bearer token override (default: your opschain login session, then $OPSCHAIN_ADMIN_TOKEN, then the token stored by opschain admin login). |
Exit codes: 0 on success (including "nothing to reassign"), 1 when either identity does not exist, the target is not an enabled service account, or the token is rejected, 2 for the connection usage errors.
See also
opschain docs cli/admin-service-accounts— create and manage the targets.opschain docs cli/admin-users-disable— the disable that warns about stranded automations.opschain docs cli/triggers-update— repoint a single trigger'srun_asby hand.