Supplier connections: draft, test, publish, roll back

A connection is one supplier's whole integration, versioned. Instead of editing a live mapping and hoping, you change a draft, test it against real orders, and publish it as a new numbered revision — with the old one kept for rollback.

You don't create connections by hand: one appears automatically under Connections when you configure a supplier's mapping, output, or delivery.

What one revision bundles

Each revision is a complete snapshot of how orders for that supplier are processed:

• the input mapping (how your file's columns become canonical order fields),
• the output mapping and output format (what the supplier receives),
• the delivery setup (protocol, configuration, auto-deliver on/off),
• the validation profile (which acceptance rules check orders),
• the item-code mappings and catalog mode.

The day-to-day editing still happens in the supplier's own editors (mapping, delivery, validation tabs). The connection page is where you version, test, and publish those changes as one unit.

The lifecycle: draft → test → publish → archive

1. Draft — create a draft revision, usually cloned from the live one. Drafts are the only editable state.
2. Test — run the test pack. ProcuLink replays recent real orders through the draft and runs a conformance check. Nothing is delivered during a test. The result is stored honestly: a failed pack is recorded as failed, not hidden.
3. Publish — flips the draft live. Publishing requires a passing test run that is at least as new as your last edit — editing a draft clears its old test evidence, so you re-test after changes. Publishing archives the previously live revision; one revision is live per connection at a time.
4. Archive — published revisions that get replaced become archived. Archived and published revisions are immutable — they can't be edited, only cloned into a new draft.

Every order is pinned to a revision

When an order arrives, it records exactly which revision processed it. That pin never changes, so:

• you can always see which mapping, rules, and output produced a given order,
• publishing a new revision never rewrites history — old orders keep validating and re-rendering against the revision they ran under,
• rolling back doesn't disturb orders processed in between.

Replay: see the impact before you publish

From any revision you can replay recent orders (up to 50 per run) through it without delivering or saving anything. For each order you get a diff against its current result: how the output text changes, which effective field values change, and which validation checks flip between pass and fail.

Differences are information, not automatic failures — a changed output may be exactly what you intended. Read the diff, then decide. The hard gate is the test pack: publish stays blocked until a test run passes.

Rollback

If a published revision turns out wrong, open a previously published (now archived) revision and roll back to it. ProcuLink clones its full bundle into a new published revision with the next version number and archives the bad one — the history stays intact, and orders pinned to any earlier revision are unaffected.

Connection editing vs supplier tabs

• Use the supplier's tabs to change the actual content: field mappings, item codes, delivery config, validation rules.
• Use the connection page to control when those changes go live: create a draft, test it, replay orders through it, publish, or roll back.

Next: Editing the output your supplier receives — the per-order mapping tools a revision snapshots.