Open your app's Data panel, choose the table, and open the record you want to change. Edit its fields and save. Editing stored data does not require a builder message.
What a save does
A save updates the selected row's submitted fields in one database update and keeps its ID. The response reads the record back from the database. Reopen or refresh the record to check the stored result.
This is not an optimistic-locking editor: it does not refuse a save merely because another person changed the row after you opened it. Avoid simultaneous edits to the same record. For balances, counters or a custom approval workflow, ask the builder for explicit server-side concurrency rules rather than using the Data panel as that workflow.
Delete with care
Export the table before a cleanup. Delete only records you have identified as test data, and check related records first. Deleting a row does not mean every other table that refers to it is automatically cleaned up.
The Data editor attempts to make a restore point before updates and deletes. Do not rely on that as your only backup, and do not confuse a data restore point with Version History: restoring app code is a separate operation.
Preview and the live app use the same app database. Removing a record through Preview can affect the live app too.
Archive instead of deleting
If your app needs an archive, ask the builder to add a status or archive field and update the relevant queries. Hiding an archived row from a list is not a privacy rule; enforce access on the server too.
See Exporting your data.