Roll back a deploy

Rollback runs as a new tracked operation. It promotes a previously built immutable release image; it doesn’t reread Git or Workspace and doesn’t delete or rewrite the original history row. Phase names and terminal outcomes are defined in Deploy states and phases.

Confirm rollback eligibility

Open the deploy that introduced the problem and review Actions. The portal derives rollback eligibility from the previous serving release, the type of change, and the available recovery path. Phase alone doesn’t determine eligibility.

If Rollback is disabled, read the reason shown below it. Common reasons include a first release with no previous version, a configuration operation that must be reversed through its settings page, or missing recovery information. Self-service rollback is currently unavailable for a deploy that ran a breaking database migration; contact support to evaluate that recovery.

Request a data-restoring rollback within seven days of the original deploy. After that window, the required pre-deploy recovery point may no longer be available.

Before continuing:

1. Verify that this deploy introduced the problem.
2. Record current customer impact and recent writes.
3. Review Changes to identify database migration risk.
4. Confirm that a forward fix isn’t safer.

Code-only or additive changes

For code-only releases and releases with additive database changes, rollback promotes the prior immutable release image. Data written after the release remains. Additive schema may remain until a later maintenance change removes it. The pre-migration backup taken for an additive deploy isn’t restored automatically because doing so would discard writes accepted while the old release remained live.

Select Rollback, review the confirmation, and select Confirm rollback. The portal tracks the new rollback deploy until it reaches a real outcome. A successful submission isn’t the same as a completed rollback.

Breaking database changes

Self-service rollback for a breaking or unclassifiable database migration isn’t currently enabled. Contact support instead of attempting to work around the disabled action. The decision flow below applies only when the portal offers this rollback path.

After a breaking migration has served traffic, synsmarts can’t decide whether discarding post-migration data is acceptable. The rollback panel presents a data-impact assessment. Measurements that are unavailable are unknown, not zero.

Choose based on business knowledge:

• Forward-fix (keep data) keeps the current release and all data while you prepare a corrected deploy.
• Roll back code only (keep data) promotes the prior immutable release image without reversing the database. Use it only when that release is compatible with the migrated data.
• Restore database from backup returns to the pre-deploy database and permanently deletes newer writes.
• Point-in-time restore, when offered, restores to the selected recovery point and permanently deletes later writes.
• Cancel rollback leaves the current deploy unchanged.

Danger

Silence never authorizes data loss. A data-destructive rollback requires an explicit choice, and the restore options above permanently delete newer writes. If the assessment is unavailable, treat the possible loss as unknown and contact support before choosing a destructive action.

Submit the decision within 24 hours. If no decision arrives, synsmarts cancels the rollback automatically, keeps the current release live, and discards no data. Start a new rollback request if the original request expires.

Configuration changes

A configuration rollback reapplies the prior configuration as a new App operation. Follow that operation in Deploys until it completes.

When a configuration deploy isn’t eligible for the code rollback action, return to the originating settings screen, restore the intended values, and apply them as a new operation.

Follow the rollback

The original deploy page reports the rollback state:

• Rolling back means the new operation is active.
• Rollback decision needed means a database-changing rollback requires an explicit resolution.
• Rollback complete means the selected prior immutable release is live.
• Rollback failed means the App remains on the pre-rollback version.
• Still confirming means the portal hasn’t yet found the new rollback record; don’t submit another request while it continues checking.

If the portal can’t reach the server to check status, the rollback can still be running. Restore connectivity and wait for a confirmed outcome.

Verify the result

After rollback, verify the live App, its primary transaction path, and any data whose compatibility motivated the rollback.

Rollback doesn’t change the connected repository, automatic-deploy setting, or Workspace. Workspace can therefore contain newer code than the release now serving. Inspect it before a later Workspace deploy.

For a code-only rollback, confirm recent data is still present. For a data-restoring rollback, compare business-critical records against the chosen recovery point and resume integrations only after the data state is accepted.