Objects
Quick actions
Publish record-level actions that users can run from object records and tables.
Quick actions
Quick actions covers record-level published actions that staff run from object records to update data, start workflows, run scripts, or create work. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: record-level published actions that staff run from object records to update data, start workflows, run scripts, or create work.
- Where users start: Quick actions are configured at
/settings/objects/:objectId/quick-actions. - Where administrators configure it: Users run published actions from record detail pages such as
/objects/:objectName/:itemId/view. - Runtime/detail surface: Quick actions are staff-triggered operations for moments where the user decides the process should run.
- Platform connections: Quick actions connect object records, scripts, workflows, permissions, form inputs, side effects, and logs.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Quick actions are configured at /settings/objects/:objectId/quick-actions. | Day-to-day work and review. |
| Configuration | Users run published actions from record detail pages such as /objects/:objectName/:itemId/view. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Quick actions are staff-triggered operations for moments where the user decides the process should run. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Quick actions are configured at
/settings/objects/:objectId/quick-actions. - Review the configuration route and permissions before changing live behaviour: Users run published actions from record detail pages such as
/objects/:objectName/:itemId/view. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Header action, Form-backed action, and Script-backed action first because they shape the rest of the rollout.
- Add Workflow trigger and State transition only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Quick actions are staff-triggered operations for moments where the user decides the process should run.
- Check downstream connections after saving: Quick actions connect object records, scripts, workflows, permissions, form inputs, side effects, and logs.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Header action | Users need a visible record operation | Show on record detail. |
| Form-backed action | Users must provide extra input | Keep fields minimal. |
| Script-backed action | Operation needs code | Use object scripts and playground. |
| Workflow trigger | A wider process should start | Pair with Workflow Studio. |
| State transition | Record should move stage/status | Validate required fields first. |
| Restricted action | Only certain roles should run it | Configure permissions and visibility. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Header action and Form-backed action.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.
- /developer/scripts-api
- /developer/script-patterns
- /reference/side-effects
- /reference/objects-records