Workflow Versioning

When working with workflows, it's important to understand when and why to version them. Not every change requires a new version, but when you're dealing with in-progress workflows or updates that affect downstream logic, versioning ensures you don’t break anything mid-execution.

Versioning allows:

• Existing submissions to finish their workflows as-is
• New submissions to follow the updated path
• Confidence that changes won’t impact active processes

When Should You Version a Workflow?

You should version a workflow if you're making changes that:

• Add new nodes early in the process, especially before any deferred nodes
• Update existing nodes to produce new outputs that are referenced later
• Introduce new joins, junctions, or logical forks in execution
• Change the structure or behavior of referenced routines

These changes can impact workflows already in progress — so versioning protects those in-flight.

🧠

If your workflow has no deferred nodes or routines, it's usually safe to make changes directly, but the larger and more complex the workflow, the more cautious you should be.

Versioning Trees

Versioning a tree is straightforward: clone it, update the clone, and preserve naming conventions based on your source system.

For Kinetic Request CE (or Other Systems Using Webhooks)

If your workflows are triggered by external webhooks, like form submissions in Kinetic Request CE , the tree name must remain the same. That's because the webhook path includes the tree name, and any change would break the trigger.

Recommended approach:

1. Clone your existing tree (e.g., Submit → Submit_v1)
2. Use the clone (Submit_v1) as a backup
3. Work directly on the original tree (Submit) to implement your updates

This keeps the triggering path intact while preserving the prior version if you need to roll back.

Versioning Routines

Routines are a bit more complex because they may be referenced in many places. Ideally, you want:

• In-flight executions to finish using the current version
• New executions to use the new version
• No need to manually replace every node where the routine is called

The Elegant Versioning Pattern

1. Clone your routine (e.g., SendNotification_v1 → SendNotification_v2)
2. Disconnect the current Start node in the original routine
3. Connect the Start node to a new node that calls your updated routine (v2)
4. Pass inputs from the v1 routine into the v2 routine
5. Return the outputs from v2 back up through v1

This keeps the version structure clean — no cascading updates, no deepening workflow branches.

Routine Version 2

Routine Version 3

You can repeat this versioning approach again and again — v3, v4, etc. — while maintaining a stable outward-facing routine.

Best Practices

• Always consider if your update might impact in-flight workflows
• If in doubt — clone it out! (Trees and routines are lightweight to duplicate)
• Document your versioning pattern to help your team stay consistent
• Don’t forget to update associated routines, operations, or notifications when versioning workflows

What’s Next?

• Cloning and Importing Workflows
• Reusing Logic with Routines
• Debugging Workflows with the Runs Tab