Publishing and governance

Configuration changes have different lifecycles depending on the asset. Review the entity's actual controls and save state. An edit saved in Studio can still be unpublished; a published Automation can still be inactive; a promoted configuration can still need target runtime setup.

Know which action changes what

Asset/action	Result
Save a versioned Studio draft	Preserves editable work without replacing its live publication.
Save a named checkpoint	Creates a history point for later review/restoration.
Publish Material, Work Center, BoM or Routing	Makes the reviewed definition available in that scope and records a version.
Publish App	Creates the usable version; later draft edits remain separate.
Save table	Applies its schema directly; Tables have no separate publication action.
Publish document/Label template	Makes the selected reusable layout available; existing outputs keep their captured content.
Publish Automation	Validates and stores the workflow publication.
Activate Automation/Recipe	Enables its intended automatic/runtime use.
Promote Test to Production	Reconciles supported configuration in the selected site's target environment.
Finalise report	Fixes one report revision and its PDF; does not publish its source template.

Permissions to design, publish, assign, execute and release are distinct. A successful preview does not grant authority to perform the next action. Konnie uses the same scoped services and approval/dependency controls as Studio.

Review a change before publication

Confirm the intended site/environment and asset. Wait for saving to complete, review the current draft and inspect dependencies. Use the available preview with typical, empty and variant inputs. For a graph, inspect every branch and terminal path.

Read validation messages and open the affected node or field. Fix missing references, incompatible types, required mappings, unconfigured providers and unavailable recipients before publishing again. Do not replace a denied dependency with a guessed identifier.

Add a release note that explains the operational effect, such as “Require batch number before final inspection”. Publish the exact reviewed draft, then verify the publication by reopening it or using the consumer. An autosave or a closed confirmation dialog is not the same evidence as a usable published version.

History and restoration

History/checkpoints support inspecting earlier saved content and publications. Restoring a history entry normally creates editable draft content. Compare it with the intended dependencies and publish it when it should become live. Restoring a template does not rewrite already issued documents; correcting a report creates a new revision.

If the editor reports a version conflict, another change has been saved. Reload the latest record, compare your intended update and apply it again. Keep the original information you need before reloading unsaved work. Do not repeatedly overwrite a newer draft.

Release Test configuration to Production

With release authority and the intended site selected, open Test to Production from the scope release controls. Preview permission can be granted separately from apply permission. Apply uses preparation rights in Test and release rights in Production. Choose Everything, Categories or Selected objects, and review the field changes, dependencies and issues.

Everything and Categories retain objects that exist only in Production. Physical removal through promotion, reset or revert is blocked: a reference scan cannot exclude a concurrent runtime record. Archive or remove configuration through its native target lifecycle before continuing. A direct Production change or missing shared baseline requires an explicit decision for that object. Direct Production editing remains available to authorized users.

Publish source drafts before transferring their definition. The preview identifies selected unpublished source work instead of silently transferring an older saved definition. Target staging and source publication are separate actions. Reset uses the published Production definition and identifies ignored source drafts.

Apply is bound to the reviewed preview. If either workspace or a target draft changes, refresh and review the new preview. The release commits as one transaction; a later validation/write failure leaves its earlier configuration changes unapplied. If the result is unknown, check release history before retrying.

The release plan is configuration only. Runtime orders, history and production bindings are preserved rather than copied from Test. Dependencies may add objects to your explicit selection. Repair blocking issues and refresh the preview before applying; a successful source preview does not establish that Production has every required runtime connection.

Work-center configuration changes apply immediately while current orders, operational status and metrics stay in the target. A dirty target work-center draft blocks an ordinary transfer; a clean editor follows the transferred definition. Review this immediate effect separately from staged target artifacts.

The normal release stages target drafts for Apps, Labels, document templates and Automations. It preserves current target publications, audience, execution locks, owners and execution identities. Publish and activate in the target with the corresponding permissions. A release does not copy a source publication number or make a new Automation active. Unsupported fixed runtime references and table/view bindings must be resolved before their package can move. Inactive Recipes receive a target draft/checkpoint; changes to an active target Recipe use its native lifecycle.

Standalone Forms are retired and cannot be transferred. Materials, BoMs and Routings transfer through their native target drafts and checkpoint history. Their live definitions and default selections remain in place until native publication. Unpublished target changes block a transfer; review and publish or discard them in the target first. Complete dependency packages translate component materials, work centers and routing references into target identities. Native publication still requires the corresponding target editing and publication permissions.

After application, review recent release history and inspect the target configuration. Check App audience/assignment, enabled workflows, secure integration access and any operator-managed runtime setup in the target. Perform one agreed target test of the actual workflow.

Reset Test from Production refreshes supported Test configuration and replaces the reviewed Test drafts. Save work you want to keep first. The preview includes dirty drafts even when the underlying saved definition is unchanged. Operational orders, results and history remain in Test; reset is not an empty test database or a copy of Production runtime activity.

Transfer between other environments

Open Release → Between environments…, then select the source and target within the current site. Each pair gets its own permissions, preview and target history. Changing either environment discards the previous preview. Equal source/target selections cannot be applied. All conflict, dependency, credential, draft and unknown-outcome protections above also apply. Cross-site transfers are not supported.

Revert a promotion

In Recent releases, choose Revert for the relevant completed promotion and inspect its preview. Revert restores configuration changed by that promotion while preserving runtime history and production bindings. An inverse of a published artifact becomes a new target draft for review and publication; it does not rewind a live publication pointer, Automation grant or schedule. A changed target draft also blocks a stale inverse.

Revert is blocked when a target object was changed, removed or recreated since the promotion, when the inverse would physically remove a created object, or when an older updated artifact receipt lacks authoring/publication metadata. Restore those older designs through the native target editor. Material inventory history and unit restrictions remain authoritative. Resolve the specific conflict with the responsible owner; a blind revert is not a general recovery from operational data changes.

Verify the operational result

Open the published target App as its intended user. Check the required data and run one authorized test action. Read the destination record or report, and inspect run/print history where relevant. Check an account that should be denied when access has changed.

Keep these outcomes separate in handoffs: saved, published, active, promoted, operationally verified. See Roles and permissions, Konnie approvals and Audit logs.