Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.seal.run/llms.txt

Use this file to discover all available pages before exploring further.

​
What is a change set?

A Change Set is a collection of drafts and related entities undergoing changes together. This ensures that related changes are grouped together, reviewed comprehensively, and published in sync. A screencast showing the Change Set interface.

​
What can be part of a change set?

Whenever a draft is created, it is automatically assigned to a change set and all edits are made within that change set. A screencast showing how a new draft is added to a Change Set. A Change Set can consist of one standalone entity or multiple related entities. Add entities using the plus symbol, where you can add an existing entity or create a new one.
  • Adding an existing draft entity will move it to this change set.
  • Adding a published entity will create a new draft of that entity in this change set.
Note that submitted entities belong to the same change set as their parent entity. A screencast showing multiple related entities being added to a single Change Set.

​
Reviewing and publishing

To review and publish any entity, it must go through a change set process. All entities in the same change set are reviewed together — all review requirements from included entities are combined.
Learn more about Review Requirements here.
A screencast showing the review requirements for a Change Set. An approval is required for all review conditions before publishing. When a change set is approved, all included entities are published at the same time.

​
Delayed activation

Delayed activation is available only on orgs with the Delayed SOP Activation feature enabled. Contact your Seal admin if you need it switched on.
Some regulated workflows — particularly SOPs and policies — need a soak window between publication and becoming the active version. The new version is available for training and review the moment it’s published, but day-to-day work keeps following the prior version until the soak window elapses. At publish time — in the publish dialog, each entity whose type allows it (instances and templates) shows a Delay activation toggle and a days input. Tick the entities that should soak; siblings activate immediately as usual. The default soak window is configurable on the org’s organisation config (sopActivationDelayDays). During the soak window — the new version exists as pending_activation. Its training requests target the new version, but Active vX on the entity still points at the prior version. A clock-icon banner appears on the entity page showing when auto-activation is scheduled. First publish (v1) — delaying the first published version of an entity leaves it with no active version at all until the soak elapses. Training routes to v1 immediately, but users who only have view access can’t open the entity yet — to them it doesn’t exist as an active document until the cron (or an “Activate now” override) promotes it. Adjustments after publish — admins with change-set permission can use three buttons on the pending-activation banner:
  • Activate now — promote the new version immediately, skipping the rest of the soak window.
  • Extend +7 days — push the auto-activation date further out (useful if reviewers need more time).
  • Cancel auto-activation — clear the schedule entirely. The entity keeps its prior active version indefinitely, until an admin activates manually or a later change set publishes a new version.
Every adjustment — and the eventual activation itself — is recorded in the audit trail with the acting user, the reason (auto_activate_after_soak vs manual_soak_override), and the originating change set, so the soak window is fully traceable for compliance reviews.

​
Viewing all change sets

View all change sets from the tab in the top bar. The 'Change Sets' tab in the main navigation bar.