Once a datastore has rows, every row gets an action toolbar — typically including View, Edit, Copy, Delete, and an audit history button. Whether each action is available to a user depends on their permissions on the underlying datastore.
Edit and Delete are the two most heavily-used actions, and both deserve a clear understanding because misuse — particularly of Delete — can be hard to undo.
Edit
Clicking Edit opens the same form used for creating a row, pre-populated with the row's current values. The user changes whatever fields they want and clicks Save.
Behind the scenes:
- Validation runs again — required fields must still have values, validation rules still need to pass.
- Audit log records the change if audit mode is on. The before/after values for every modified field are captured.
- Post-update callbacks run after save — same hooks as post-insert.
- Triggers on the datastore fire if configured.
If audit mode is enabled, every change is recorded with the user, timestamp, and the field-level before/after values. That trail is visible from the row's Audit History button — useful for debugging "who changed this and when?".
Delete
The Delete button looks destructive but it isn't, by default. Delete is a soft delete — the row's MSTisdeleted column flips from 0 to 1 but the data remains in the database. Hidden from normal listings but recoverable from the Trash view.
Why soft delete instead of hard delete? Three reasons:
- Accident recovery. Most data is deleted by mistake. Soft delete gives you a one-click undo.
- Audit trails. Records survive long enough to satisfy compliance retention rules without admins having to remember to back up.
- Referential integrity. Other rows that reference the deleted row don't break — the linked row is still there, just flagged.
Note: Soft delete is platform-wide. Even rows you've "deleted" from a datastore are kept until a separate hard-delete operation (usually scheduled, or run by an admin) actually removes them. That's an important detail for compliance regimes that mandate true deletion of personal data — you need a hard-delete process on top of soft-delete to fully purge data.
Copy
The Copy action duplicates the row into a new draft, ready to edit. Useful for templates or near-identical records — a copy of last month's invoice, a re-run of a previous order, a near-duplicate customer record where most fields stay the same.
The new row gets a fresh ID and timestamps. Linked rows (e.g. line items on an order) are typically copied too if the datastore is configured for it, but check your specific datastore's behaviour — defaults vary.
Where the action toolbar appears
The full toolbar (View / Edit / Copy / Delete / Audit History) appears in three contexts:
1. The standard data list
Open the datastore via View Data and you see every row with its action buttons. This is the admin-side default.
2. Browse Views
Customisable end-user listings where you decide which actions appear. A browse view for customers might show only View and Edit; one for orders might add a custom "Mark as Shipped" action.
3. User-facing pages
When a row is exposed via a Friendly URL or embedded in a Page Builder page, the actions are typically pared down to just the ones relevant for the role consuming the page.
Permission requirements
Each action checks the user's permissions against the datastore:
- View requires Read.
- Edit requires Edit (which implicitly assumes Read).
- Copy requires both Read (to see the source) and Write (to create the copy).
- Delete requires Delete.
- Audit History requires Read.
Without the relevant permission, the corresponding button simply doesn't appear. That's a clean UX — users don't see buttons they can't use — but it can be confusing during debugging ("why isn't the Edit button there?"). The first thing to check when a button is missing is the user's permissions for that datastore.