Service change management
Change management is the service’s version history and the safest way to undo or restore Builder changes. Every saved version records its version number, time, change description and user. Deployment history is shown alongside the version where available.
Open a service and select Change management, or use Undo/redo in the utility navigation.
Understand the history
| Column | What it tells you |
|---|---|
| Version | The sequential service version, such as v42. |
| Time of change | When the version was created, shown in your local time zone. |
| Deployment history | Environments to which that exact version was deployed, with deployment details. |
| Change description | A readable summary of fields, components, pages or settings changed. |
| User | The Builder user or authorised process that created the version. |
Some entries provide Load technical change detail for a more detailed comparison. Use it when the readable summary is not enough to assess impact; do not require ordinary reviewers to interpret raw service data for every change.
Undo and restore are non-destructive
The current row offers Undo latest change when a previous version is available. Earlier rows offer Restore this version.
sequenceDiagram
participant H as Existing history
participant U as Builder user
participant C as Current service
U->>H: Choose an earlier version
H-->>U: Show the selected state and change context
U->>C: Restore this version
C->>H: Create a new current version based on the old state
Note over H,C: The intervening versions remain in historyRestoring v38 while the current service is v42 does not delete v39 to v42 and does not renumber the current version back to v38. It creates a new version whose content is based on the selected state. You can therefore inspect or restore the later work again if necessary.
Undo the latest change
- Open Change management immediately after noticing the problem.
- Read the current and previous change descriptions.
- Confirm that no one else has made a valid change after the one you intend to undo.
- Select Undo latest change.
- Return to the affected page or setting and inspect the result.
- Test the journey in User view.
Undo works at service-version level, not at the level of one field in a batch of saved changes. If the latest version contains both wanted and unwanted edits, restoring the previous version removes both; it may be safer to correct the unwanted setting manually.
Restore an older version
Use an older version when several changes must be rolled back or when you need a known design as a new starting point.
Before restoring:
- compare all relevant history rows, not only the first description line;
- check which versions were deployed to QA or Production;
- tell current editors and avoid overwriting unsaved work;
- record why the restore is needed and what will be retested.
After restoring, inspect service settings, pages, conditions, actions, integrations and languages that changed since that version. A technically successful restore may reintroduce an old defect or obsolete endpoint.
Relate versions to deployments
Change management records service design versions; the Environments screens decide which saved version runs in QA or Production. Restoring a version changes the current Builder state but does not automatically deploy it.
Likewise, deploying an older version to an environment does not change the current design. This separation supports rollback without discarding later design work.
flowchart LR
A[Current Builder version v43] --> B[Prototype reflects current design]
C[Previously saved v40] --> D[Deploy selected v40 to QA]
C --> E[Deploy selected v40 to Production]
D -. does not change .-> A
E -. does not change .-> AWork safely with other editors
Check the user and time on the newest rows before restoring. If a version appeared after you opened the page, refresh and reassess. The Builder protects individual updates with version checks, but a restore is still a deliberate change to the whole service state.
Add a clear manual correction after a restore when necessary so the next history description explains the operational intent.