Activity logs

Recorded activity

audit:read permits Settings → Activity logs. The page retrieves the integrity summary automatically.

Administrative actions record:

• the acting user, service account, host, or system identity;
• a bounded action key such as vendor.credentials.rotate;
• the target type and optional safe target identifier;
• success, failure, or denied;
• a bounded reason code and correlation identifier when applicable;
• the browser, service-account, application, host, or system source; and
• the readable model/activity summary and date shown in the table.

Search by actor, model, or activity and move through paginated history. A safe search example is a model such as vendor_connection or an administrator's approved display name; never paste a KYC identifier, credential, token, or raw payload into the search field.

Verification-result access

OneView records result-preview access and verification-detail views separately for each affected verification. Successful access and denied attempts are both recorded, so a client can review who attempted to reveal a stored result and whether OneView allowed it.

These activity events do not contain normalized result fields, identity values, photos, submitted request data, or other result contents. audit:read permits review of the safe activity record; it does not grant access to the verification result itself. During an access review, record only the safe verification reference, action, actor, outcome, and timestamp shown by the installed release.

Structured filters

Use Structured filters when a broad text search is ambiguous. Filters combine with one another and with the search field:

Action and target keys start with a lowercase letter and use only lowercase letters, numbers, dots, hyphens, or underscores. Reason codes use uppercase letters, numbers, and underscores. Invalid filters are rejected before the request is sent. Select Clear to remove both applied and unsaved structured filters.

The current results table remains a compact summary. Filtering by a structured field does not make hidden event metadata, credentials, verification payloads, or provider errors visible in the browser.

Integrity status

The page displays whether the available activity history passed OneView's integrity check. A failed check may indicate damaged or changed history and must be investigated under the client's incident process.

Database, operating-system, Docker, and network logs remain the client's responsibility.

The current page supports search, structured filtering, and pagination but not event-detail, export, deletion, or repair. If retrieval fails, keep the filters unchanged and retry once. If the integrity check fails, preserve evidence, restrict recent infrastructure access, and follow the client's incident process; do not alter records to make the indicator pass.

Safe investigation example:

1. Filter Outcome to Denied.
2. Select the expected source and actor type.
3. Add a known documented reason code, when available.
4. Record only the safe action, target type, reason code, actor display name, and timestamp.
5. Correlate locally with approved infrastructure logs without copying request bodies, credentials, or KYC data.

Activity records are not a substitute for the client's privacy, retention, incident, or data-subject request evidence. Apply the data-boundary and shared-responsibility guide to application and infrastructure logs, exports, backups, and support attachments.