Goal: improve an existing app while preserving information and expected access.
For Team tasks, begin with something like renaming a view or adding an optional priority field. Think through existing records and any views or rules that depend on the changed field.
Use preview data to check the result. Confirm that the project saved successfully and that the intended revision is selected before preparing a release.
Frontends in a project share its backend and can reuse the same pages. A change is not isolated merely because you opened one frontend first. Review affected interfaces and access rules.
Before a destructive change, understand what would be removed and how dependent views and workflows would behave. Do not assume that returning to an older screen restores deleted information.
Use Publish to inspect checks and create the new release. Read the current serving state and make the intended release live only when authorized and available. Reopening the live address should show the release you intended, not just the latest preview.
Stop making further changes while you establish which release is live and what was affected. Use the available pause or earlier-release controls where appropriate and permitted.
An earlier application release, restoring data, and correcting an external action are different recovery tasks. A rollback is not a promise to undo every consequence.