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
  • Setting the date
  • Shifting the date
  • How the date shows up across the app
  • Clearing a target
  • Gotchas
  • Related
Onboardings

Target launch dates

Pivotal's source of truth for when an onboarding should go live, and what tracks slip.
|View as Markdown|Open in Claude|
Was this page helpful?
Previous

Move through phases

Next

Phase templates

Built with

The target_launch_date is the single field Pivotal uses to decide whether an onboarding is on track. Pi’s forecast, the Workbench risk lane, and the customer-facing portal all read from it. Every other timeline signal in the app is derived.

Setting the date

You set the target on creation: the New onboarding dialog has a date picker beside the customer selector. Leaving it blank is allowed; the onboarding opens with target_launch_date: null and the Workbench shows it as No target.

To set or change the date afterwards, open the onboarding and click the Target launch field in the header. Pi recalculates the forecast as soon as the value saves.

Shifting the date

A target launch date isn’t a wish, it’s a commitment. Shifting it asks for a reason and writes a target_shifted event to the audit log. The reason is required when the new date is more than 7 days later than the previous one.

The shift history appears in two places:

  • Onboarding > Header > Target launch: hover the date to see the last three shifts.
  • Audit log: filter by event type target_shifted to see every move and the reason behind it.

Pi reads shift frequency as a risk signal. Three shifts inside a single phase moves the onboarding into the at risk lane regardless of how far out the new date is.

How the date shows up across the app

  • Workbench: sorted into This week, Next week, Later, and No target lanes.
  • Reports: On-time launches is the count of onboardings whose actual launched_at is on or before their final target_launch_date.
  • Customer portal: visible to the customer unless you hide it in portal settings.
  • Pi: quoted directly in summaries (“Acme is 4 days from target, currently in UAT”).

Clearing a target

Set the field to empty in the Target launch picker. The onboarding moves into the No target Workbench lane and drops out of forecast reports. Pi stops surfacing it in launch forecasts but still tracks at-risk signals from task overdue counts and phase duration.

Gotchas

  • Customer-facing onboardings without a target read as low-confidence to your customer. The portal shows “TBD” in place of the date, which prompts inbound questions. Set a placeholder date and shift later rather than leave the field empty.
  • Time zones use the workspace default set in Admin > Workspace settings > General. A date entered as “May 26” is May 26 in the workspace zone, not the viewer’s local zone.
  • Shifting backwards (pulling the date in) doesn’t require a reason but still writes to the audit log. Pi treats a pull-in as a positive signal and lowers the at-risk score.
  • If you set the date in the past, the onboarding flips to overdue the next time Pi runs (every 15 minutes).

Related

  • The phase model
  • Onboarding states
  • Forecast launches with Pi

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