Change saved data safely
Plan model changes, protect existing records, verify in development, and release data updates in a safe order.
On this page
Changing stored data can affect forms, lists, validation, permissions, and every existing record. Start in Plan, describe the records that already exist, and verify the whole data journey before publishing.
Describe the change in Plan
Name the current concept, the new customer outcome, and what must remain true for old records. For example:
Plan a change that adds an optional repair-notes field to bookings. Existing bookings must continue to open without notes. Show where staff can add notes, keep customer pages unchanged, and explain how to verify the change in development. Do not build yet.
Review the field type, defaults, relationships, validation, access, and affected screens. Ask what happens to old rows; required, renamed, or removed fields can break them.
Prefer an optional addition with a clear empty state. Plan any later required-field change separately. Do not approve deletion until the plan identifies what will be lost.
Build the model and its screens together
Approve the plan, then build the data change and affected read and write paths together. The edit form must save repair notes, the staff view must display them, and old bookings must still open.
If the schema rollout stops safely or needs attention, do not publish. Return to the conversation with the visible result and revise the plan.
Verify the data journey
In Runtime → Data, select the authority you used for testing. Then:
- open an old record and confirm its existing values still display;
- create a new record through the changed form;
- find that row and compare the new value with the app;
- refresh and reopen the record;
- try missing or invalid input and confirm no partial row appears.
Check lists, summaries, and filters that use the field. For private records, repeat the journey with two accounts and while signed out.
Before publishing, read the data-authority notice. Publishing does not copy development rows to protected production data. After publishing, repeat one old-record read and one new-record journey with safe information.
If a step fails, return to Plan with the screen, authority, safe test record, and result. Do not hide an app defect by trying to repair rows through the inspection view.
Next: Inspect tables and rows and troubleshoot an app build.