omni-admin

Rotating invalidates the previous key — confirm with the user before running, and re-register the new public key wherever the old one was trusted.

# Rotate a connection's dbt commit signing key
omni connections dbt-rotate-signing-key <connectionId>

# Rotate a model's git commit signing key
omni models git-rotate-signing-key <modelId>

This is the canonical access check other skills defer to (e.g. omni-content-builder / omni-model-builder deciding whether a new field goes on a branch vs a workbook model). Run omni whoami whoami --model-id <modelId> and read rolesByModel[<id>].permissions. Gate on the presence of permissions, not the role name — names can be renamed custom roles and surface as internal codes (e.g. QUERY_TOPICS):

Decision shortcuts:

• Where should a new model field live? QUERY_FULL_MODEL present → a shared-model branch (merge it yourself if you also have UPDATE, otherwise open a PR / request a merge — a Querier can branch and modify but not promote); QUERY_FULL_MODEL absent but USE_WORKBOOKS present (Restricted Querier) → the document's workbook model (extension). A Viewer can't author content, so they never reach this choice.
• What a Restricted Querier can change in the workbook model — view-scoped only: add dimensions/measures to an existing view (extension mode) and edit decorations on existing fields (label/format/description/hidden/synonyms). They cannot modify a topic in any way (expose a field, change joins/topic config, create a topic) or change access grants / other governance — those need QUERY_FULL_MODEL on a shared-model branch. So don't plan a topic-scope, join, or grant change for a restricted querier's workbook model; it 403s mid-build and can leave the document half-modeled.
• What a Restricted Querier can query — topics only. QUERY_TOPICS without QUERY_FULL_MODEL means every query they author must be topic-based (table = the topic's base view + join_paths_from_topic_name). A bare base-view query or a raw-SQL userEditedSQL tile needs QUERY_FULL_MODEL (full-model + SQL access) — so it isn't an option for a restricted-querier author; build every tile on a topic. (Distinct from visibility: even a Querier-authored non-topic tile is hidden from restricted/Viewer audiences unless Access-Boosted.)
• A shared-model-scoped whoami does not list branch ability as its own entry — branch create/use is a separate capability granted to Querier+ — so use QUERY_FULL_MODEL as the proxy. (Holds for base roles; a custom role could grant one without the other — confirm when it matters.)

# Roles are keyed by the MEMBERSHIP id, NOT the user id (a user id → 404 "Membership … not found").
# Get it — yourself: whoami → user.membershipId · another user: scim users-list (its `id` IS the membershipId, see note below)
omni users get-model-roles <membershipId> --model-id <modelId>
omni users assign-model-role <membershipId> --body '{ "modelId": "<modelId>", "roleName": "<roleName>" }'

# Group variants
omni users user-groups-get-model-roles <groupId> --model-id <modelId>
omni users user-groups-assign-model-role <groupId> --body '{ "modelId": "<modelId>", "roleName": "<roleName>" }'

Resolving another user's membershipId needs the org key. whoami → user.membershipId is self-only. For someone else, omni scim users-list --filter 'userName eq "them@company.com"' returns the membership as its id (which is the membershipId — not the user's user.id). But the SCIM API accepts only the org-level API key: a user-scoped PAT/OAuth is rejected with "User-scoped API keys are not allowed to access the SCIM API." The get/assign-model-role calls above work with a user PAT — only this lookup needs the org key.

• The body key is roleName (not role), and the path id is the membership id (a user id returns 404).
• roleName is a server-validated, instance-specific string — base roles (e.g. QUERY_TOPICS, QUERIER, CONNECTION_ADMIN) plus any org custom roles. The valid set is not discoverable via --schema (the field is a bare string, no enum) or any list command; an unknown value returns 422 "Invalid role". Discover a valid code by reading get-model-roles on a membership that already holds the target role.
• There is no un-assign command — to revert an override, re-assign the prior role.

Access Boost lets Viewer / Restricted Querier roles view a dashboard built on non-topic content — a raw-SQL (userEditedSQL) tile or a bare base-view query — which those roles otherwise can't see. (Model access grants still apply unless the grant sets access_boostable: true.)

Dashboard-only: Access Boost lifts the restriction on the dashboard view of those tiles. It does not extend to the underlying workbook — a restricted role still can't open the workbook's non-topic or SQL tabs (or see the query behind the tile) regardless of Access Boost.

⚠️ Confirm before boosting — it loosens access controls. Access Boost deliberately exposes content that restricted roles can't otherwise see, and non-topic / raw-SQL tiles bypass topic-scoped governance (access filters, always_where) — so boosting can surface data those controls would normally withhold. Do not apply Access Boost autonomously or as a reflexive fix for "they can't see it." First:

1. Understand what the document exposes — what data the boosted tiles show, at what grain, and whether any of it is sensitive.
2. Confirm intent with the requester — that they really mean to grant these specific Viewer / Restricted Querier users or groups visibility into that content. State the implication back to them and get an explicit go-ahead before running the command.
3. Prefer the narrowest scope — boost specific users/groups (add-permits) over the org-wide organizationAccessBoost; reach for org-wide only when that's explicitly what's wanted.
4. Note the governance interaction — model access grants still apply unless a grant sets access_boostable: true; don't treat that as a safety net, confirm intent regardless.

Prerequisite (org capability, not in the CLI): the org must have allowsDocumentAccessBoost enabled (and allowsMemberToProvisionAccessBoost for non-admins to grant it). This is an instance/admin setting — if it's off, the document-level flags below are silently cleared. It's a gate; it does not itself turn Access Boost on anywhere.

Once you've confirmed intent, there are two activation levers, both scoped to a single document:

# Boost specific users/groups on this document (add-permits / update-permits)
omni documents add-permits <documentId> --body '{
  "userGroupIds": ["group-uuid"],
  "role": "VIEWER",
  "accessBoost": true
}'

# Boost the "everyone in the org" principal on this document
omni documents update-permission-settings <documentId> --body '{
  "organizationAccessBoost": true,
  "organizationRole": "VIEWER"
}'

update-permission-settings (PUT) also carries the document's other toggles — canDownload, canDrill, canSchedule, canUpload, canUseDashboardAi, canUseTimezoneOverride, canViewWorkbook, requirePullRequestToPublish. Note organizationAccessBoost boosts the org-default principal on this document only — it is not an org-wide switch.

# After creating or updating a user, verify they exist with correct state
omni scim users-list --filter 'userName eq "newuser@company.com"'

Check that: active matches what you set, displayName is correct, and the user ID was returned (not an error).

# After creating a group or modifying members, verify membership
omni scim groups-list

Check that: the group exists with the expected displayName, and members array contains the expected user UUIDs.

# After setting document permissions, verify the principal and role
omni documents access-list <documentId>

# For a specific user, also check effective permissions
omni documents get-permissions <documentId> --user-id <userId>

# After setting folder permissions, verify
omni folders get-permissions <folderId>

Check that: the principal is listed and the role matches what you set (VIEWER, EDITOR, etc.).

# Verify the user's assigned attribute value was set
omni scim users-list --filter 'userName eq "user@company.com"'

Check that: the response contains the target user, the user's urn:omni:params:1.0:UserAttribute object includes the requested attribute name, and the value exactly matches what you set. omni user-attributes list only verifies that the attribute definition exists.

If the attribute is used for row-level security (access_filters), test it by running a query as the target user:

omni query run --body '{ "query": { ... }, "userId": "<target-user-uuid>" }'

Verify the results are correctly filtered — the user should only see rows matching their attribute value.

# Verify schedule was created with correct settings
omni schedules list -o json

# Verify recipients were added
omni schedules recipients-get <scheduleId>

Check that: the created schedule id appears in the list and the returned fields match the requested schedule cron, timezone, destinationType, content, format, and dashboard identifier. If the list/get response shape is not parseable, report that schedule setting verification was inconclusive instead of silently treating an empty parser result as success. Always verify recipients with recipients-get.