Skip to content

Update packages

An update package bundles a set of related changes — content items, deleted items, and optionally a site’s structure changes — so they can be reviewed and deployed together. Instead of each edit going live on its own, your changes accumulate in the package as working copies. When the package is approved and merged, all of its changes are applied to the main repository (and the site, if one is attached) at once.

A package has a name, an optional description, and a list of the items it contains. Items in a package are separate working copies: editing an item inside a package does not touch the version in the main repository until the package is merged. A package can also carry a site, in which case it holds its own copy of that site’s page structure.

If your repository has workflow enabled with a default workflow, creating a package automatically submits it for review — see Submitting to workflow.

You add them. Select content and use the Add to Package action to put items into an Existing Package or a New Package. Editing a site inside a package works the same way — pages you change are pulled into the package automatically (see Edit site pages).

A rule adds them when you save. Your administrator can set up rules that match certain content types or categories. When you save a matching item, a dialog appears:

  • Add to Package? — the rule recommends review. Choose a package and click Submit to Package, or click Skip — Save directly to save without one.
  • Package Required — the rule is strict: the item must be saved into a package and go through workflow. Choose an existing package or create a new one (a name is suggested for you), then click Submit to Package. A Skip workflow — save to repository option appears only if you hold a special permission.

When choosing an existing package, the list only offers active workflow packages you can act on — packages assigned to you, or unassigned packages whose current step belongs to one of your groups.

Every package has a review page (dashboard queue rows and package lists link to it). It shows:

  • A header with the package name, its workflow status, and — for reviewers — action buttons.
  • Tabs listing what the package contains:
    • Site Structure Changes — additions, removals, and updates to the attached site’s page tree (only for packages with a site).
    • All Package Items — every item in the package.
    • New Items — items that do not exist in the main repository yet.
    • Deleted Items — items the package will delete on merge.
    • Main Repository Items — the current main-repository versions of the package’s items, for comparison.
  • The workflow steps, current assignee, and full workflow history, if the package is in workflow.

You can remove items from a package here, and refresh a package item with the latest main-repository version if it has changed since.

You can also work with packages from the Asset Browser: the Packages panel in the sidebar lists the open packages for your repository with a status pill — In Progress (in review) or Merge (ready to merge) — and a Merged toggle that reveals already-merged packages. Selecting a package opens its items so you can edit them in place.

If someone edits the live site while your package is open, a banner on the package review page reports how many changes were detected in the base site. Update from Base Site lets you pick which of those changes to pull into your package, so the merge does not undo other people’s work.

Merging applies the package to the main repository:

  • Each package item is created in, or updated over, the main repository copy.
  • Items in the Deleted Items list are removed from the repository.
  • If the package carries a site, the site’s page structure is replaced with the package’s version.

Merging is confirmed in a Merge Package dialog with two options: Publish merged items and (for site packages) Publish site after merge. If you leave them off, merged changes land as drafts and are published separately. Depending on your repository’s configuration, the merge — and publishing — may instead happen automatically as soon as the workflow completes; in that case the dialog shows the publish options as required.

A merge cannot be undone. After merging, the package becomes a read-only record: its review page shows who merged it, when, and what was merged and published.