Skip to content

Releases

The Releases app groups stories into a release that publishes as a unit, either manually or on a schedule. Use it to prepare a campaign ahead of time and to keep an upcoming launch visible only to the people working on it.

  • Group stories into a release by theme or by date.
  • Publish a release manually or schedule it.
  • Review upcoming releases in a calendar, switching timezone.
  • Compare a release with the current content and resolve mismatches, individually or in bulk.
  • Restrict a release to selected users and roles.
  • Issue a release-based access token for reading an unpublished release from the API.
  • Track permission changes in the activity log.

Install the app from Apps → Releases.

To create a release, open the Content section, select New Release +, and configure the release. To schedule the publication of a single story, add it to a release.

To fetch the content of a release, update the API calls of your frontend to pass the release ID in the from_release parameter.

To review all scheduled releases in chronological order, open the Content Planner and navigate between dates with the calendar on the left. The calendar view supports the following actions:

  • Switch the time zone
  • Filter scheduled and unscheduled releases
  • Manage releases

When someone changes a story outside the release it belongs to, a warning badge appears next to the story in the release, in the Content section. To resolve the mismatch, open the story in the Visual Editor:

  • To resolve all conflicts at once, select Resolve conflicts at the top, then Accept All Changes or Reject All Changes.
  • To resolve one conflict, select Resolve conflict next to the block or field, review the change, and select Accept changes or Reject changes.

By default, a release is public: every user with general access to the space can view and edit it. Restrict a release to limit editing and previewing to authorized users, and use release access tokens to control API access.

Release permissions follow these rules:

  • The user who creates a release is its owner.
  • The owner grants access to specific users or roles and can transfer ownership to another user.
  • Permissions can change at any point in the release lifecycle.
  • The activity log records every permission change.
  • Space admins have full access to all releases, regardless of these settings.
  1. In the Content section, select the release to edit, or select + to create one.
  2. Under Restrict release access, select Restricted.
  3. Configure the options that appear:
    • Select users and roles: the users and roles that can view and access the release. This setting also applies to review requests.
    • Select access tokens: the release access tokens that grant API access to the release. If you select no token, API access is public.
    • Release owner: the owner of the release. Defaults to the user who created it.

Only authorized users, individually or through a role, can view or interact with a restricted release.

Release owners and space admins create and manage release access tokens:

  1. Open Settings → Access Tokens and select New Access Token.
  2. In Access level, select Release.
  3. In Restricted Releases, select the releases the token can access. You can change this selection later.

A Content Delivery API request for a restricted release without sufficient access returns 403 Forbidden. The release owner and space admins can bypass the restriction with their personal access token.

Was this page helpful?

What went wrong?

This site uses reCAPTCHA and Google's Privacy Policy (opens in a new window).Terms of Service (opens in a new window) apply.