Skip to content
ChecktivChecktivChecktiv Docs

Staff actions

View as MarkdownOpen in ChatGPT(opens in new tab)Open in Claude(opens in new tab)

The staff actions log records actions Checktiv staff take against your data: action verb, timestamp, and the resource touched.

What counts as a staff action

Section titled “What counts as a staff action”

A staff action is anything a platform employee does that touches resources in your organization — starting a support session, unmasking an applicant’s personal data, stopping an impersonation session, or billing-side adjustments (goodwill grants, out-of-band wire funding, refunds, wallet balance changes, or SKU price overrides).

Actions that do not touch customer data are not surfaced here. Visibility is set per capability, and the log layers a defensive filter so a misconfigured flag cannot leak a non-staff row into this view.

Open the staff actions log

Section titled “Open the staff actions log”

The staff actions log is its own Staff actions page, separate from the activity log. Reach it from the link in the staff-impersonation banner shown while a staff member is active in your organization, or by opening its direct page link. Unlike the activity log, which is Owner/Admin-only, this page is visible to every organization member.

Each row shows the timestamp, the action, the actor type (Support engineer, Internal service, or Automated), and the resource. Individual staff identities are suppressed.

Dual-approval workflow

Section titled “Dual-approval workflow”

The highest-impact staff actions require dual approval before they can run. A second staff member must approve, and the approver cannot be the requester — enforced as a hard constraint.

Capabilities that touch customer data and require dual approval:

  • Starting an impersonation session against a customer organization.
  • Unmasking applicant personal data inside a verification.
  • Wallet balance adjustments, rate overrides, and SKU pricing overrides.

Internal staff-administration actions (such as assigning a staff role to a teammate) also require dual approval, but happen entirely on our side and are not surfaced in your log.

Dual approval pairs with fresh MFA, WebAuthn for the highest-risk capabilities, a required ticket reference, and time-boxed auto-expiring sessions.

Active impersonation sessions

Section titled “Active impersonation sessions”

While a staff member is impersonating a teammate in your organization, the console shows a persistent banner with the actor’s role, the purpose, and the expiry. The banner stays in sync across browser tabs. The stop event records the reason and appears in this log.

What we will and will not do

Section titled “What we will and will not do”

Staff can do — every action below is recorded in this log:

  • Start a time-boxed impersonation session with dual approval, a ticket reference, and only against the authorized region.
  • Unmask applicant personal data with dual approval, when a ticket justifies it.
  • Apply billing adjustments within cap-bounded controls.

Staff can do — recorded internally, not in this log:

  • Read your verifications and configuration to resolve a ticket you raised. Read access is recorded in our internal audit log but is not surfaced in your staff-actions feed.

Staff cannot do:

  • Act outside an approved capability — every action is checked against the staff capability registry.
  • Self-approve a dual-approval action.
  • Act against EU-resident data from a non-EU-authorized session, or vice versa.
  • Edit, delete, or hide a customer-visible audit row.

Raising a concern

Section titled “Raising a concern”

If you see an action you do not recognize, copy the timestamp and resource identifier and open a support ticket. We will respond with the ticket reference, the staff role, and the approval chain.

Section titled “Related”