Configuration Versions and Rollback
Every configuration change you make to an application Component in SVIEW —
an image tag update, a values change, a parameter edit — is automatically
recorded as a version. You can review that history at any time and, if a
recent change causes a problem, roll back to a version that was working.
Where to find it
- Open the application Component.
- Go to the Versions tab.
You will see a list of past versions, newest first, each with:
- Age — when the change was made
- Author — who made it (a teammate, or an automated pipeline)
- Version — an identifier for that specific change
- Type — what kind of change it was (Values update, Parameter change,
Metadata change)
Reviewing a version
Click any row to open its details: the exact values in effect at that
version, and a diff showing what changed relative to the version before it.
This is the fastest way to confirm exactly what changed and when, without
needing to ask your platform team to pull logs.
Rolling back
If a recent change is causing problems, you can revert to any earlier
version directly from its details view:
- Open the version you want to revert to.
- Click Rollback.
The platform redeploys your application using that version's configuration
— the same deployment path as any normal change, so you get the same
validation and rollout behavior. There is no separate "instant undo"
mechanism; a rollback is a redeploy, so expect the same brief rollout time
as any other configuration change.
A few things worth knowing:
- Configuration only. Rollback reverts the application's deployment
configuration (image tag, values, parameters). It does not revert
database contents, persistent storage, or any other runtime state — if
the problem is data-related rather than configuration-related, rollback
will not fix it. - The history keeps moving forward. After a rollback, the Versions list
shows your application is now running the older configuration again, but
it does not insert a special "rollback" entry — treat the Versions list
as "what configuration has been active over time," not as an undo log. - Some production services require approval. If the Component is
configured as a protected/critical service, a rollback (like any change)
may need a second person to approve it before it takes effect. If you
see a message asking for approval after clicking Rollback, that is
expected — it is not stuck.
When to raise a request instead
Rollback covers configuration-level problems. If the issue is in your
application code itself (a bug in the image you deployed, not in how it is
configured), roll back to a known-good image tag the same way, then fix and
redeploy the code separately. If you are not sure whether an issue is
configuration or code, see
Workload Management
for how to tell the difference, or raise a request.
Related articles
Updated about 6 hours ago