Skip to main content
Version: v5.6.1

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.

Semantics worth knowing:

  • Only the executing identity moves. Authorship (created_by) stays historical on every row; the automation's run_as now 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​

FlagMeaning
--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's run_as by hand.