Configuration
Xchange works with versioned configuration snapshots. At any given time there is exactly one active configuration that drives running operations. Alongside it there can be a draft — a working copy in which changes to connections, routes, and value tables are prepared.
While a draft exists, all edits go into it. The active configuration stays untouched. Only when the draft is validated and then activated does Xchange adopt the new settings for operations.
This principle has two important consequences: running operations are never interrupted by a configuration change — they always finish using the state they started under. And faulty configurations cannot accidentally affect operations, because activation is only possible after a successful validation.
What Validation Covers
Validation looks at the draft as a whole: mandatory entries, references between routes and connections, and the logical consistency of the configuration. It works exclusively on the draft itself — no external system is contacted, no connection is opened, no data is transferred.
A passed validation therefore says that the draft is consistent in itself. It does not say that the connected systems are reachable — that is what the connection test is for — nor what the activation changes in substance; that is what the comparison shows.
Exactly One Draft
There is always at most one draft at a time — never several parallel working states. Every change, regardless of which route or connection it touches, accumulates in the same draft until it is activated or discarded. This restriction is deliberate: a single draft can be validated as a whole and activated as a whole — there are no competing working states to choose between, and no question of which of several drafts should go live next. If an already-validated draft is edited further, its status switches to Validation Outdated: the last result stays visible but no longer applies to the current content until it is validated again.
Earlier States Are Kept
Every activation creates a new configuration snapshot; the previous one is not overwritten but archived. Two possibilities follow from that, and both make changes less nerve-racking.
Compare puts two states side by side and shows field by field what differs — usually the draft against the active configuration, which is exactly what the next activation would bring about. That answers, before the activation, what actually ended up in the draft over days and across several editors.
Restore brings an archived state back: it becomes the active configuration again, and the previously active one moves into the archive in turn. Nothing is lost in the process, and an existing draft stays untouched. So there is always a way back — even after an activation that turns out to be wrong.
Transferring Configuration Between Systems
A configuration snapshot can be exported as a file and imported into another system — e.g. to carry a configuration built in a test environment into production after sign-off, or to take a backup before a larger change. The export contains connections, routes, and value tables in full, but deliberately no credentials: passwords, client secrets, and tokens stay in the source system and must be re-entered in the target system.
An import only ever creates or extends the target system's draft — never its active configuration directly. Imported configuration therefore follows the same path as any manually made change: validate first, then activate. This keeps operations protected even while configuration moves between systems.