For AI agents: a documentation index is available at the root level at /llms.txt and /llms-full.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
DashboardGet an API key
SetupCustomersOnboardingsWorkbenchAsk PiIntegrations
SetupCustomersOnboardingsWorkbenchAsk PiIntegrations
  • Onboardings
    • Overview
    • The phase model
    • Move through phases
    • Target launch dates
    • Phase templates
    • Onboarding states
    • Task completion
    • Subtasks
    • Comments and attachments
    • Audit log
LogoLogo
DashboardGet an API key
On this page
  • What an entry looks like
  • Event types you’ll see most
  • Filtering and searching
  • Workspace-wide audit (Pro plans)
  • Retention
  • Examples
  • Gotchas
  • Related
Onboardings

Audit log

Every change on an onboarding, filterable by actor and event type, retained for the life of the workspace.
|View as Markdown|Open in Claude|
Was this page helpful?
Previous

Comments and attachments

Built with

The audit log records every state-changing action on an onboarding: field edits, phase moves, task completions, comments, attachment uploads, template applications, integration sync events. It’s append-only and lives on the Audit tab of every onboarding page. Workspace-wide audit (across every onboarding) sits in Admin > Audit log on Pro plans and above.

What an entry looks like

Each entry carries:

  • id: opaque entry ID, shown as Audit > #1432 in the UI.
  • event: the action type, e.g. phase_changed, task_completed, target_shifted, state_changed.
  • actor: the user, system process, or integration that triggered it.
  • timestamp: UTC, displayed in the workspace time zone.
  • target: the resource the entry is about (the onboarding, a task, a comment).
  • diff: before-and-after values for field changes, or the structured payload for events.
  • reason: optional, present for events that required one (phase send-back, target launch shift, manual state changes).

Event types you’ll see most

  • onboarding_created: the initial creation.
  • phase_changed: every advance, send-back, or skip. See Move through phases.
  • state_changed: active to paused, paused to active, active to done.
  • target_shifted: every change to target_launch_date, with the old and new values.
  • task_created, task_completed, task_reopened, task_assigned, task_due_date_changed.
  • comment_posted, comment_edited, comment_deleted.
  • attachment_added, attachment_removed.
  • template_applied: auto or manual application of a phase template.
  • webhook_delivered and webhook_failed: outbound delivery results.
  • notification_skipped: when a notification was suppressed (muted recipient, paused state, customer-side opt-out).

Filtering and searching

The Audit tab has two filters at the top:

  • Actor: pick a teammate, a customer contact, or System for automation.
  • Event: multi-select from the event list above.

Searching by text matches against diff payloads and reason fields. Useful for finding “who shifted the target by more than two weeks last month.”

Workspace-wide audit (Pro plans)

Admin > Audit log is the same data, aggregated across every onboarding. Filter by customer, by event, by actor. Export to CSV via Export > CSV; the export carries the same fields as the on-screen view. For real-time consumption, subscribe to the audit.entry_created webhook.

Retention

Entries are retained for the life of the workspace. There is no auto-prune. Deleting a customer or an onboarding moves the entries into a retained-but-hidden state; they reappear if the customer is restored.

Examples

  • A CSM debugging why an onboarding flipped to at risk: filter by event: state_changed and read the reason.
  • A compliance request for “every change to acme.com in Q1”: open the workspace audit log, filter by customer, set the date range, export to CSV.
  • An engineer chasing a webhook outage: filter by event: webhook_failed and read the diff for the response code.

Gotchas

  • Audit entries don’t capture reads. There’s no record of who opened an onboarding or viewed a comment.
  • Comment deletions retain the original body inside the audit entry for compliance, even though the comment is gone from the timeline. Don’t write things in a comment you wouldn’t want surfaced under audit.
  • The actor is the user that initiated the action, not the user that ended up touching the data. A bulk task complete from a saved Workbench view records the user who clicked Mark complete.

Related

  • Move through phases
  • Comments and attachments
  • Webhooks overview

Email help@pivotal.app with a screenshot of where you got stuck and the customer or onboarding id from the URL.