Permissions

Permission model

Permissions control access to client administration and verification functions. A user receives permissions through their one assigned role.

Common responsibility areas include:

• Users and roles.
• Branding.
• Vendor connections.
• Verification execution and review.
• Customer KYC workflow configuration and its change history.
• License visibility and refresh.
• Activity-log visibility and integrity verification.
• Network inspection, health checks, and host-change authorization.
• Software-update status, signed release checks, and access to the exact host update command.
• AI provider setup, assistant use, and conversation oversight.

OneView hides navigation and actions the user cannot access and also enforces permissions when an action is requested. Hidden navigation alone is not a security boundary.

The dashboard requires authentication but no additional page permission.

Application permissions

• vendors:read permits the vendor connection list and details.
• vendors:manage permits connection creation, preferred selection, credential rotation, and enable/disable actions. Assign vendors:read as well so the manager can navigate to and review the page.
• verifications:read permits metadata-only locally stored verification history. It does not reveal normalized result fields, result-derived table previews, or verification detail views.
• verifications:results:read appears as View verification results and permits bounded result previews and stored normalized result details. Assign verifications:read as well so the reviewer can navigate to verification history.
• verifications:execute permits New Verification on a licensed Sub-module's Verification page. The history table remains read-only.
• branding:read permits the current branding profile, preview, and history.
• branding:manage permits save, logo/default changes, and confirmed history restore.
• license:read permits license visibility.
• license:manage permits online license refresh; it does not edit commercial terms.
• users:read permits the user and role lists.
• users:manage permits local user lifecycle, temporary-password reset, role assignment, and non-immutable role creation/update.
• audit:read permits activity search/pagination and automatic integrity verification.
• service_accounts:manage permits human administrators to list, create, rotate, and revoke service accounts. It does not let a service account administer credentials.
• transaction_settings:read permits viewing the institution base currency used by transaction monitoring.
• transaction_settings:manage permits the one-time base-currency configuration. Assign transaction_settings:read as well so the administrator can navigate to and verify the setting. It also permits enabling or disabling automatic AI transaction investigation when the AI and provider prerequisites are ready.
• ai:use permits the header context-chat assistant and the user's own AI conversations. AI tools still enforce the permission required for the underlying read or action and the relevant client license entitlement.
• ai_provider:read permits the AI provider/model configuration list without revealing credentials.
• ai_provider:manage permits testing and saving provider keys, rotating a key, enabling or disabling an eligible configuration, and selecting the installation default. Assign ai_provider:read as well for page navigation.
• ai_conversations:manage permits the all-users AI conversation page, message review, search, and archive actions.
• transactions:read also permits starting or retrieving an AI transaction investigation when the AI Module and a ready default provider are available. There is no separate transaction-investigation permission. This operation saves derived Markdown but cannot change the transaction decision or analyst review.
• cases:read permits the case list and case detail.
• cases:create permits creating a case.
• cases:manage permits investigation edits, tasks, notes, evidence links, and non-final workflow transitions.
• cases:evidence:read permits bounded evidence snapshots, subject to the permission and license required for the source record.
• cases:restricted:read permits viewing, creating, and editing cases classified RESTRICTED, including restricted-case fields in lists and exports. Without it, a restricted case is invisible even to a user who otherwise has cases:read.
• cases:assign permits changing a case's owning team or individual assignee.
• cases:decide permits resolution, closure, and allowed reopening transitions.
• cases:export reserves access to approved case exports when the installed release provides them.
• case_settings:read permits viewing the case taxonomy (types, dispositions) and related settings.
• case_settings:manage reserves access to institution-managed case settings when the installed release provides editing.
• teams:read permits viewing teams and their membership under Settings → Teams. Case ownership uses teams, not case-specific queues; a case does not exist without both an owning team and an individual assignee.
• teams:manage permits creating, editing, deactivating, reactivating, and managing membership of teams. Team membership never grants case or other module permissions by itself.

Every signed-in user can view and revoke their own browser sessions. users:manage additionally permits the all-sessions view and revocation of another user's session or every active human session. See Active sessions.

Every signed-in user can also view and manage their own My Account page (details, self-service email notification preference, and their own activity log) with no separate permission required. See Users, roles & permissions.

• redis:read permits viewing whether the shared Redis connection is configured.
• redis:manage permits testing and saving the Redis connection. See Redis.
• email:read permits viewing whether the SMTP connection used for notification emails is configured and previewing the notification email template.
• email:manage permits testing and saving the SMTP connection, plus sending a real test email to the acting user's own address. Configuring Redis is required first. See Notifications.
• reports:read permits viewing the Reporting report lists, detail, transactions, parties, and generation history.
• reports:manage permits creating and editing reports and recording supported lifecycle changes.
• reports:export permits generating and downloading goAML XML.
• reports:approve permits deciding a pending maker-checker approval level the user is named on.
• report_settings:read permits viewing Reporting readiness and settings.
• report_settings:manage permits managing institution profiles, contacts, mappings, schemas, and automatic generation schedules. See Reporting.
• customers:workflows:read permits viewing Customers → Workflows and the KYC checks configured for each customer type. The page also requires the KYC Module in the active license.
• customers:workflows:manage permits Configure and saving a workflow, which always records a change reason. Assign customers:workflows:read as well so the administrator can navigate to the page and confirm the result.
• customers:workflows:history:read permits the read-only Version history for a workflow. It is separate from customers:workflows:manage, so a reviewer can oversee policy changes without being able to make them. See Customer KYC workflows.
• customers:workflows:runs:read permits the Runs tab on the Workflows page: the onboarding and scheduled runs OneView has performed and each run's per-check outcomes. Without it the tab is not shown. It permits no configuration change.
• Running the onboarding checks for a bulk-imported batch requires both customers:bulk_import and customers:workflows:manage. Importing customers and committing the institution to the vendor spend of checking them are deliberately separate rights, so an operator with customers:bulk_import alone can import a batch and see what onboarding it would run, but is not offered the action that starts it. See Workflow runs.

Role design

Avoid giving every user the system administrator role. Create roles around operational duties and review them when new Modules, Sub-modules, or administrative features are introduced.

The system administrator role initially includes View verification results. Custom roles do not receive it automatically; an administrator must explicitly assign it when the role's approved duties require access to sensitive stored results.

Exact permission keys are listed in the Roles interface for the installed release. Documentation for a new client function must state which permission controls it.

AI does not expand a user's role. Before an AI tool reads data or prepares an action, the backend checks the user's underlying permission and the client's current Module or Sub-module entitlement. Most write tools also require an explicit, expiring confirmation. No AI tool provides record deletion. See AI in OneView.

Service-account permissions

service_accounts:manage permits a human administrator to create, list, rotate, and revoke service accounts. Service accounts cannot use that administrative permission themselves.

API Service Accounts are not assigned dashboard roles or permissions. An active credential can call all public integration APIs made available by the installed licensed Modules and Sub-modules. It cannot use the dashboard or setup, administration, user, role, branding, network, license, software-update, or credential-management endpoints. Possessing its API key does not bypass Module, Sub-module, capacity, connection, or license enforcement. See API Service Accounts for credential handling.

Network permissions

• network:read permits current network-setting inspection and safe health checks.
• network:manage permits the same inspection plus proposal staging, cancellation, and host-command generation.

Applying an approved proposal remains an explicit host-administrator action. See Hostname & networking.

Software-update permissions

• updates:read permits viewing the installed version, last online check, available update, progress, and outcome.
• updates:manage includes status visibility and permits Check now plus viewing and copying the version-bound host update command.

Applying an update remains an explicit host-administrator action. See Updates & versions.