Deploying scripts & managing versions

Introduction

Scripts are versioned, and saving is separate from deploying:

• Saving a version stores your work. You can save and test as often as you like, without affecting anything that's live.

• Deploying a version releases it. When you deploy, you can also choose which process flows using the script should move onto the new version — so rolling out a change everywhere is a single action.

Need to know

• A script can hold up to 10 versions. Once the limit is reached, no more versions can be added until you delete enough old ones to bring the count back down.

• Deploying a different version is also how you roll back — if a change causes problems, simply deploy the previous version again.

• Every change and deployment is recorded in the platform logs, so you can always see who changed a script, when it was deployed, and which flows were updated.

Deploying a version

Follow the steps below:

Step 1 Open your script and go to versions > deploy.

Step 2 Choose the version to release from the version to deploy dropdown. The selected version is shown read-only, so you can confirm exactly what you're about to release — if the version you've selected is already live, a confirmation banner is displayed:

Step 3 Deploy the version. From this point, it's the live version of the script.

Updating flows that use this script

The flows using this script panel (right) gives you full visibility of where the script is used — every process flow is listed, together with the version it currently uses.

To move flows onto the version you're deploying:

Step 1 Tick the flows you want to update. The change each flow will receive is shown alongside (for example, v1 → v2) — flows already on the selected version are flagged, so there's nothing to do for those.

Step 2 Click the update button (for example, update 1 flow) — each selected flow is updated to use the new version.

Only a flow's draft can be changed. A live flow keeps running its currently deployed script version until you deploy the flow itself — so updating a script version never changes live behaviour behind your back.

Pinned versions & rollbacks

Wherever a script is attached (a script shape, map shape, connector endpoint, etc.), it references a specific script version — as shown in the currently uses column on the deploy page. This means:

• Deploying a new script version doesn't force it on anyone — flows move onto the new version when you update them (above) and deploy them.

• To roll back, deploy an earlier version and update the relevant flows onto it in exactly the same way.

If you'd rather a given usage always picks up your newest release, select the use latest version option where the script is attached — those usages follow whichever version is deployed, with no need to update them each time.

Audit trail

Script changes and deployments are captured in the platform logs — including who edited a script, when versions were deployed, and which flows were updated to use them. This gives you a complete history for troubleshooting and change control.