Skip to content

Node Versioning

Lime CRM nodes carry a version number, and every node you add to a workflow is pinned to the version that was current when you added it. When a node needs a breaking change, the change ships as a new version rather than altering the existing one — so a node can have more than one version available at the same time, and existing workflows keep running on the version they were built with. This page explains why that matters and how to work with node versions.

Why Node Versions Exist

Nodes evolve over time — new operations are added, parameters change, and outputs are improved. Some of these changes are not backwards compatible: a renamed parameter or a changed output structure could break a workflow that was built against the old behavior.

Node versions let a node change without breaking existing workflows. When a new version introduces a breaking change, the previous version stays available, and workflows that were built on it keep running exactly as before.

This is why a node can have more than one version available at the same time — for example version 1 and version 2 of the Lime CRM node. New workflows use the latest version; existing workflows stay on the version they were built with.

Node version is not the package version

The node version (1, 2, 1.1) is separate from the version of the node package that is installed on your instance. The node version only describes the behavior of an individual node inside a workflow.

Versions Are Not Updated Automatically

Upgrading the Lime CRM nodes does not change the nodes already in your workflows.

When you add a node to a workflow, its version is stored with the workflow. Installing a newer version of the nodes makes the new version available for new nodes you add — it does not touch nodes that are already placed in existing workflows. Those keep running on their original version.

This is intentional: it guarantees that upgrading never silently changes how your existing workflows behave.

The trade-off is that moving an existing node to a newer version is a manual step. Until you do it, an existing node continues to use its original version and does not benefit from changes introduced in newer versions.

How to Update Node to Its Latest Version

When a new node version is available and you want to use it in an existing workflow:

  1. Open the workflow and locate the node.
  2. Add a fresh instance of the node from the nodes panel — new nodes always use the latest version.
  3. Re-select the resource and operation, and re-enter the parameters, using the Node Reference and the version's release notes as a guide.
  4. Reconnect the node in place of the old one.
  5. Test the workflow before activating it.

You only need to do this when you specifically want the improvements from a latest version. If your workflow works as expected, there is no requirement to upgrade its nodes.

When a New Version Is Introduced

A new node version is only introduced when a change would otherwise break existing workflows — for example:

  • A parameter is renamed or removed
  • The structure of a node's output changes
  • The default behavior of an operation changes

Backwards-compatible improvements — such as a new optional parameter or an added operation — are generally made in place and do not require a new version. Bug fixes that do not change how a node behaves are also made in place.

When a breaking change ships as a new node version, it is called out in the release notes so you can decide whether and when to move your workflows to it.

Summary

  • Every node is pinned to the version it had when you added it to a workflow.
  • Older versions stay available so existing workflows keep working.
  • Upgrading the nodes does not update nodes already in your workflows — that is a manual step.
  • Only move a node to a latest version when you want the improvements it brings, and always test afterwards.