ConnXL Docs

Operate

Versions

Every environment keeps a restorable history of published configurations. This page covers the draft-vs-live model, saving and publishing a version, comparing two snapshots (including your unpublished draft), restoring, and promoting a version across environments.

7 min read

The draft-vs-live model

Every environment has two things going on at once: a working draft (whatever your connections, functions, ribbon buttons, and taskpane currently look like in the dashboard) and a live version (a saved snapshot that's actually being served to Excel).

  • Editing is always a draft. Adding a function, changing a connection, tweaking the taskpane — none of it creates a version, and none of it reaches Excel on its own.
  • A version is created only deliberately — by Save version or by Promote. There's no automatic "edit" version; that's why a just-built function still returns nothing until you publish.
  • Live is a pointer, not a copy of the draft. The environment points at one saved version; the agent serves exactly that version's snapshot. An environment with no live version yet serves nothing — its agent shows zero functions.

Why a brand-new function returns blank

If you just built a function and the cell shows nothing (or the agent's config looks empty), you almost certainly haven't published. Go to the environment's Versions page and Save version with "Make this version live" checked — that's the only action that pushes your draft to the agent.

Save a version

From the environment's Versions page, Save version snapshots the current working draft under a name you choose. Its modal has one toggle:

  • Make this version live (on by default) — publishes the snapshot immediately; the agent starts serving it.
  • Turned off — saves a checkpoint without changing what's currently live. Useful for capturing a milestone mid-edit without shipping it yet.

Make live

Any saved version in the history can be made live again with one click — a Make live action that just moves the live pointer to that version. It doesn't touch your working draft and doesn't create a new version; it's a pure publish/rollback switch. Use it to roll back to a known-good version after a bad publish, or to re-promote an older version without re-running Promote.

Compare

The Compare action (or ticking two rows in the history) opens a full-page diff between any two versions. The two pickers are:

  • From — any saved version.
  • To — any saved version, or a special Current state option (badged Draft) that fetches your raw, unversioned working draft straight from the environment's live tables.

Comparing a saved version against Current state is how you see exactly what publishing would change before you do it — the same check that drives the "unpublished changes" banner on the Versions page. To compare against the environment's live version specifically (not the draft), pick it from the version list — the row the history marks Live.

Current state is not the same as the live version

Even when nothing looks different, "Current state" is always your live working draft re-read fresh — it is deliberately not a cached copy of whatever the live version's snapshot was. Comparing against it is the only way to see unpublished edits; comparing two saved versions only ever shows published-vs-published differences.

The diff classifies each changed item as added, removed, or modified, and for modified items shows exactly which fields changed — including a flag for changes that only touch a connection's value fields (host, URL, secret reference) rather than its structure.

Restore

Restore is the older, blunter alternative to Make live: it overwrites the environment's working draft with a saved version's contents and records a restore entry. The dashboard's version rows use Make live for day-to-day rollbacks (no overwrite, no destructive warning); Restore remains available as a power action when you specifically want the draft itself replaced.

Promote across environments

Promote brings a source environment's structure into a downstream environment and publishes it there in one step — the way structural changes (a new function, a changed connection shape) reach QA, Staging, or Production. It:

  • Copies structure from the source (Development) environment.
  • Never touches the target's own values — its credentials, agent host, and cache settings stay exactly as configured for that environment.
  • Records a promote entry in the target's version history, with a title like "Promote from Development" and the diff badges to match.

Reading the history

The History timeline lists every version newest-first, each row showing:

  • A kind icon — Saved (a manual Save version), Promote, or Restore.
  • The version's title (whatever you named it, or a kind-derived fallback).
  • A blue Live badge and highlight on whichever version is currently being served.
  • The origin environment, who made the change, and when.
  • Diff badges summarizing what changed against the previous version.

Per row you can Make live, Compare (against another row), or Delete (soft; the live version can't be deleted). An amber banner at the top of the page tells you when the working draft has unpublished changes waiting for a Save version.

Versions also show up in Logs

Save / Promote / Make-live events surface in the Logs console under a "Config changes" lens, scoped to the environment you're viewing — handy when you want a chronological audit trail alongside usage analytics rather than the dedicated Versions page. See Logs & exports.

On this page