Skip to main content

Publish changes

Xignage uses a draft/publish model. Changes you make to screens, layouts, zones, and playlists are saved as drafts and don't reach the player app until you explicitly publish them. This lets you prepare and review edits safely while live screens keep showing the last published configuration.

How it works​

  1. Editing — make changes to a screen, layout, zones, playlists, or content assignments. The screen is automatically flagged as having unpublished changes, and a yellow Unpublished Changes badge appears on the screen edit page. The player keeps showing the last published config.
  2. Publishing — click Publish Changes. The platform computes a hash of the new configuration, stores it, and clears the unpublished-changes flag.
  3. Player pickup — the player polls for its display configuration. Until you publish it gets a "not modified" response; after publishing it receives the new configuration and applies it.

Publish a screen​

  1. Open the screen you've edited.
  2. Confirm the Unpublished Changes badge is showing.
  3. Click Publish Changes.
  4. The screen picks up the new configuration on its next check-in (usually within a minute).

Republish​

If you need to push the current configuration to a screen again — for example, after a player reset — use Republish. This re-sends the last published config without requiring new edits.

Change tracking​

Each publish records a timestamp and a configuration hash, giving you a version history of what was pushed and when. This is useful for auditing what changed on a screen and when.

Approval workflow​

For teams that want a review step, Xignage also supports publish requests — an approval workflow where creators submit changes and approvers accept or reject them before they go live. See Publish requests.

Next steps​