You add a Status field to your team task tracker and try it with a fictional task. Your team should not see that experiment simply because you saved it in the builder.
Preview is where you inspect and try the app you are building. Production is the environment serving a promoted release to its users. Editing and publishing are different steps.
Use preview to check the questions that matter to a person using the app:
Builder samples and starter examples are synthetic preview material. They help demonstrate a layout without supplying real operational information. Use fictional data as you learn.
Preview is not proof that every production dependency or release requirement has passed. Pay attention to validation messages and the current deployment's availability notices.
The project definition has revisions as you edit. A published release identifies a specific checked version and its maintained components. Further builder edits do not mean that users are already running those edits.
Current publishing is project-wide. Selecting a frontend does not publish that frontend independently; separate frontend releases are future work.
Availability depends on the deployed Appify version and its release gates. If publishing is unavailable or held, follow that status rather than assuming preview has made the application public.
Production has its own records, accounts, credentials, and jobs. Preview fixtures and accounts are not copied into production. A preview record link cannot be treated as a production record link.
Plan how real users will activate their production app accounts, and check production access rules before collecting information.
Returning to an earlier release changes code and configuration; it does not automatically undo records created since then. Restoring data and correcting an external effect are separate recovery actions. Avoid describing rollback as an automatic eraser.