# OMS Commands

Admin CLI commands for the UiPath Organization Management Service (OMS).

A command library composed by `admin-tool` — it owns no `uip` verb of its own. It registers its commands directly under `uip admin` (no wrapper subject group), so users invoke them as `uip admin organizations …` and `uip admin tenants …`.

## Command tree

```
uip admin
├── organizations
│   ├── get [--full]                    # --full → org + tenants + service catalog
│   ├── update [--file <path> | --name | --logical-name | --language]
│   ├── regions
│   │   └── list
│   ├── operation
│   │   └── get <operationId>
│   └── services                       # org-level services are auto-provisioned with the org
│       ├── list [--service <type>] [--status <status>] [--region <region>]
│       └── list-available
└── tenants
    ├── list [--filter <fragment>] [--service <type>] [--status <status>] [--environment <env>] [--include-services]
    ├── get <tenantId>
    ├── create [--file <path> | --name --region --environment]
    ├── update <tenantId> [--file <path> | --name | --region | --environment]
    ├── delete <tenantId>                # soft-delete only
    ├── enable <tenantId>
    ├── disable <tenantId> [--reason <text>]
    └── services
        ├── list <tenantId> [--service <type>] [--region <region>]
        ├── list-available --region <Region>
        ├── add <tenantId> [--file <path> | --service <type>]
        ├── remove <tenantId> [--file <path> | --service <type>]   # soft-remove only
        ├── enable <tenantId> --service <type>
        └── disable <tenantId> --service <type>
```

## Subjects

- `organizations` — caller's organization, async operations, and org-level services (with nested `regions list`, `operation get`, and `services` groups).
- `tenants` — tenant lifecycle and tenant-level services (with nested `services` group).

## Conventions

- Authenticated via `uip login`.
- Most mutating commands accept inline flags for common cases and `--file <path>` for full-body control. The two paths are mutually exclusive — pick one. `tenants services create` / `delete` are file-only because the body is a single complex `services{}` map.
- **Organizations cannot be created or deleted from the CLI.** The CLI deliberately omits `organizations create` and `organizations delete` — those lifecycle actions go through Portal / the support flow.
- **Hard-delete is never exposed.** `tenants delete` and `tenants services remove` use soft semantics; the request body's `isHardDelete` (where present) is hard-coded to `false`. `tenants services add` / `remove` additionally validate that every entry in the file body's `services` map has the right boolean — `true` for `add`, `false` for `remove` — to prevent an add-style file from accidentally removing services (or vice versa).
- **Org-level services are not directly creatable from the CLI.** They are auto-provisioned alongside the organization and managed by the platform. The CLI exposes `organizations services list` and `organizations services list-available` only — there is no `create` or `update-status` for org services.
- **Canary tenant routing is never exposed.** Where the SDK request DTO accepts `isCanaryTenant`, the CLI hard-codes it to `false`.
- `tenants enable` / `tenants disable` use the v2 variant of `Tenant_ChangeTenantStatus` to support reason metadata; everything else uses v1.
- `services list-available` is per-region for tenant scope (you must pass `--region`); for org scope (`organizations services list-available`) the call uses `scope=Account` with no region.