service-omni-supervisor-users-create

service-omni-supervisor-users-create

Create N supervisor users on a Salesforce org for the classic Omni-Channel Supervisor Configuration (OmniSupervisorConfig), which binds named user records via OmniSupervisorConfigUser. Users follow a deterministic supervisor{i}.<suffix>@example.com pattern so the coordinator can rediscover them across runs. It is the supervisor counterpart to service-omni-agent-users-create and shares its detection, password, and idempotency model; the only differences are the username/alias prefixes and the debug-log marker. Binding these users into a config (service-omni-supervisor-config-deploy) and granting them supervisor access (service-omni-supervisor-permset-assign) are separate leaves.

Inputs

Confirm once, up front:

• org-alias (required, no default) — must resolve via sf org display.
• Supervisor count (optional, default 1, range 1..5; the coordinator typically requests 1).
• Profile name (optional, default Standard User). The coordinator overrides this to a Service Cloud profile so supervisors consume Service Cloud licenses; supervisor access itself comes from the standard ContactCenterSupervisor permission set assigned later.

Usernames and passwords are never accepted from the operator — both are generated (usernames from the org suffix, passwords via Anonymous Apex).

Preconditions and safety

• Target org authenticated via sf CLI (My Domain URL, not .lightning.force.com), Service Cloud license present, sf CLI ≥ 2.139.6.
• The executing user has PermissionsModifyAllData and PermissionsManagePasswordPolicies (standard on System Administrator).
• Production guardrail: the detect script computes safe_to_write as IsSandbox OR TrialExpirationDate != null OR OrganizationType in {Developer Edition, Base Edition}, and the skill blocks with no override when it is false. CDOs, scratch orgs, and dev orgs are permitted.

Password handling (fail-closed). Passwords are set by Anonymous Apex System.setPassword (sf user password generate cannot target Apex-inserted users). The literal appears in the inline executeAnonymous debug log and, only when a debug-log TraceFlag is active for the running user, in a queryable ApexLog. The wrapper therefore fails closed before the first System.setPassword: it proves via a SOQL-filtered Tooling API query (ExpirationDate > now) that no active TraceFlag exists. If safety cannot be positively proven, it sets no password at all; the user is left ACTIVE, flagged password_status:"reset_required", and a security_warning explains why. It never deletes logs. A user whose password could not be set is kept ACTIVE and flagged for reset — never deactivated.