Procedure Versions

How versioning works

Every change you make in the editor is saved as a draft version. Drafts are completely isolated — you can iterate, test scenarios, even run the draft manually in sandbox, and none of it touches anything that's live.

When you're ready to ship, click Publish. The draft becomes the new default version — triggers and API callers that aren't pinned to a specific version will start using it immediately.

This model is designed to let you iterate safely:

• Edits never disrupt running procedures or live triggers
• You can test a new version thoroughly before anyone else sees it
• Every published version is preserved — nothing is ever deleted

---

Version states

State	What it means
draft	Currently being edited; not yet published
published	Promoted to live; the default version until superseded

At any point, there's one draft and one default published version per procedure. All prior published versions remain in history.

---

Publishing

To publish the current draft:

1. Open the procedure in the editor
2. Click Save to make sure all changes are persisted
3. Click Publish
4. Rapidfolio validates the graph — checks for disconnected nodes, missing required fields, etc.
5. If it passes, the version is published

After publishing:

• The new version becomes the default
• A new draft is automatically created for future edits
• The published version is locked — it can't be edited

If validation fails, the editor highlights the problem nodes so you can fix them.

---

Rolling back

Something wrong with the newly published version? Roll back immediately:

1. Open the procedure and go to Versions
2. Find the version you want to restore
3. Click Set as Default

That version becomes the default for all new runs right away. In-progress runs continue on whatever version they started with — they're not interrupted.

If you want to make further edits to the rolled-back version, click Create draft from this version to copy it into a new editable draft.

---

Pinning triggers and API callers

By default, triggers and API callers use the latest published version. Publishing a new version changes their behavior.

If you need stability — for example, a critical production integration that should only change when you explicitly decide to upgrade it — you can pin it to a specific version.

Pinning a trigger:

1. Open the trigger settings
2. Under Procedure Version, select Pin to specific version
3. Choose the version

Pinning an API call:

Pass procedureVersion in the request metadata:

{
  "data": { "customerId": "cust_abc" },
  "metadata": { "procedureVersion": "v3" }
}

Pinned callers continue using their pinned version regardless of what gets published afterward. Update the pin when you're ready to upgrade.

---

Comparing versions

Before publishing, you can compare the draft against the previous published version:

1. Go to Versions
2. Select two versions
3. Click Compare

The diff highlights added nodes (green), removed nodes (red), and nodes with changed configuration (yellow). Useful for reviewing what changed before publishing or for understanding a regression.

---

Version history

Go to Versions in any procedure to see the full history: version number, state, who published it, and when. Click any version to inspect its graph in read-only mode.