Rollouts
A rollout is a named batch of record versions with one scheduled time. At that moment it publishes the named version of each record, so a campaign spread across many records goes live together.
What a rollout holds
A rollout has a name, a scheduled time and a list of record versions. The time is required, and while the rollout is still scheduled you can edit its name, description, time and items.
It carries record versions only. Changes to models and configuration ship in a release, and a rollout can name a scheduled release to go out first. The release then ships at the rollout's moment, ahead of the content. If it is refused or fails, the rollout is marked failed with the reason and none of its content publishes.
What happens when an item fails
All the items run in one database transaction, each under its own savepoint. An item that fails is rolled back alone and recorded as failed. The others still publish, and they become visible together when the transaction commits. Afterwards the rollout reads Completed if every item succeeded, Partial if some failed and Failed if all of them did.
The controls
A scheduled rollout can be triggered early, paused and resumed, and it can be deleted until it has been triggered. Retry re-runs only the items that failed. Rollback republishes each item's previously published version. You can preview a rollback before running it, and the preview points out any item that has no earlier published version.
Where you manage them
Rollouts are managed in the console under Content, Scheduled, Rollouts, from the CLI with foir rollouts, and through agent tools. The public GraphQL API does not manage them. For CI, the documented pattern is a scheduled job that creates the rollout from a file with the CLI. Creating one needs the schedules:write permission.
Read the detail
The scheduled publishing guide covers creating a rollout, its statuses and each lifecycle control.