Save node configurations once, reuse them across journeys, and roll back when a change is wrong.
The Node Library holds reusable node configurations. Instead of re-entering the same sender address, API endpoint, or provider settings in every journey, you save that configuration once as an instance and select it wherever you need it.
Each instance is scoped to one node type. An instance created for the Email node can only be applied to Email nodes, which is what makes the fields line up.
Why it exists
Two problems it solves:
- Repetition. A workspace typically has a handful of real sender identities, API endpoints, and provider configurations, reused across dozens of journeys.
- Drift. When the same configuration is retyped in ten places, nine of them are eventually wrong. A named instance gives you one place to look.
Creating an instance
Pick the node type
Open Node Library and create an instance for the node type you want, for example Email, SMS, or API Request.
Name it for how it will be chosen
The name is what appears in a dropdown inside the journey builder, so "Transactional sender (no-reply)" beats "config 2".
Fill in the configuration
You get the same configuration fields the journey builder shows for that node type, so nothing is lost in translation between the two surfaces.
Save
The instance becomes selectable in every journey in this workspace and environment.
Versions
Every save creates a new version. The library keeps the history, and you can revert to any earlier version.
This matters because instances are shared: a change to an instance is a change to everything that uses it. If a save turns out to be wrong, reverting is one action rather than a hunt through journeys.
Using an instance in a journey
Select a node on the canvas, then choose an instance from the dropdown in its properties panel. The list is filtered to instances for that node type. Selecting one fills the node's configuration fields.
The node takes the instance's values at the moment you apply it. Later edits to the instance do not reach into journeys that already used it. Re-apply the instance in the node to pull the newer version through.
That copy-on-apply behavior is deliberate: a published journey should not change because someone edited a shared configuration elsewhere. It also means a library edit is not a way to hot-fix live journeys. To change what a live journey does, edit the journey and republish it.
Scope
Instances belong to a workspace and environment, like connectors. An instance created in Development is not available in Production, so promote configurations deliberately rather than assuming they follow the journey.