Row Actions are the buttons that appear next to each row in a Browse View — typically Edit, View, Delete, plus any custom actions you add. They're the primary way users interact with individual records on a list page.
Standard row actions
Every datastore-backed Browse View can show some or all of these standard actions automatically. Their visibility per row depends on the user's permissions on the underlying datastore:
- View — opens the row's read-only detail page. Always safe to expose to users with Read permission.
- Edit — opens the auto-generated edit form, pre-populated. Requires Edit permission.
- Copy — duplicates the row into a new draft. Requires Write permission.
- Delete — soft-deletes the row. Requires Delete permission.
- Audit History — shows every change to this row over time (if audit mode is on). Requires Read permission.
Custom row actions
Beyond the standards, add any number of bespoke actions per Browse View. For each you configure:
- Button label and icon (Font Awesome class).
- Style — primary / secondary / danger / success colour variants.
- What clicking it does — one of four destination types (covered below).
- Conditional visibility — only show the button on certain rows based on field values.
- Per-role permission — which security groups can see this action.
- Confirmation dialog — optional "are you sure?" prompt before the action fires.
The four destination types for custom actions
1. Open a URL
The simplest. Clicking the button takes the user to a URL, with merge tokens substituted from the row data. Common patterns:
/page/orderdetails/##AMDATA_id##— deep-link to a custom page.mailto:##AMDATA_email##— open the user's email client.https://external-system.com/lookup?ref=##AMDATA_refnumber##— open an external lookup.
2. Call a Javascript function
For client-side interactivity that doesn't need a page load. The button calls a function in your platform's loaded JS with the row data passed as an argument. Useful for opening modals, copying values to clipboard, triggering animations.
3. Run a Custom Form
Opens a pre-configured Custom Form pre-populated with the row's data. The form acts on the row when submitted. Examples:
- A "Quick Update" form that lets the user change just one or two fields without opening the full edit dialog.
- A "Send Notification" form that prompts for a subject and body, then emails the customer.
- A "Log Call" form that creates a child record (a call-log entry) linked to the customer.
4. Trigger an AJAX endpoint
Calls a configured endpoint in the background (no page load) with the row ID as a parameter. The endpoint does whatever you need — typically a state change on the row, like marking a ticket resolved or shipping an order.
Conditional visibility
Most row actions shouldn't appear on every row. The conditional-visibility rule lets you restrict where the button shows up. Three common patterns:
- State-based — "Mark as Shipped" only appears on rows where status = "Packed".
- Permission-based — "Cancel" only appears for users in the Customer Service group.
- Computed — "Resend Invoice" only appears when
invoice_sent_date IS NOT NULL.
Three real-world action sets
Example 1: Order management
- View — always visible.
- Edit — only when status is not Shipped or Cancelled.
- Mark as Shipped — only when status is Packed.
- Generate Invoice — only when status is Shipped and invoice not yet generated.
- Cancel — only when status is Pending.
- Refund — only when status is Shipped or Delivered, and only for Finance team.
Example 2: Ticket queue
- View — always.
- Take (assign to me) — only when ticket is unassigned.
- Resolve — only when status is In Progress and assigned to current user.
- Escalate — always for support team.
Example 3: Customer profile
- View — always.
- Edit — for customer success team only.
- Send Welcome Email — only for new customers (less than 30 days old).
- Schedule Call — opens a booking calendar pre-filled with the customer.
- Open Support Tickets — links to the tickets browse view filtered to this customer.
Tip: Don't expose too many actions per row. More than 4-5 buttons becomes overwhelming. Group secondary actions into a dropdown menu ("more actions") to keep the primary row clean.