> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.pivotal.app/llms.txt.
> For full documentation content, see https://docs.pivotal.app/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.pivotal.app/_mcp/server.

# Target launch dates

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](/product/onboardings/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](/product/setup/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](/product/onboardings/the-phase-model)
* [Onboarding states](/product/onboardings/onboarding-states)
* [Forecast launches with Pi](/product/ask-pi/forecast-launches)

Email **[help@pivotal.app](mailto:help@pivotal.app)** with a screenshot of where you got stuck and the customer or onboarding id from the URL.