Records

Records covers Dynamic object data: list views, record detail pages, files, notes, tasks, tickets, and related object panes. Use this page when you are configuring the live product surface, planning a rollout, or checking why users see different data from what an administrator sees.

What this surface is

• Primary purpose: Dynamic object data: list views, record detail pages, files, notes, tasks, tickets, and related object panes.
• Where staff start: Staff open records from /objects/:objectName/list, usually through the main menu or a launchpad shortcut.
• Where admins configure it: Object admins configure the object at /settings/objects/:objectId and tune table, view, filters, children, and automation settings.
• Runtime/detail surface: Record detail pages use /objects/:objectName/:itemId/view; inline views also exist at /objects/:objectName/:itemId/with-inlines.
• Platform connections: Records can fire object workflows, quick actions, object scripts, reports, notifications, and public or portal object forms.

Common workflows

Workflow	What happens	Where to check
Confirm the	Confirm the object name, singular label, icon, and whether staff, portal users, or public visitors should use it	Confirm in the product route above before publishing.
Build the	Build the schema first so the record form captures required sections, questions, files, and lookup fields	Confirm in the product route above before publishing.
Open the	Open the record list and configure visible columns, saved filters, sort order, and any default table layout	Confirm in the product route above before publishing.
Open a	Open a sample record and check the left overview pane, additional information, notes, files, tasks, tickets, and child records	Confirm in the product route above before publishing.

Configure it

1. Confirm the object name, singular label, icon, and whether staff, portal users, or public visitors should use it.
2. Build the schema first so the record form captures required sections, questions, files, and lookup fields.
3. Open the record list and configure visible columns, saved filters, sort order, and any default table layout.
4. Open a sample record and check the left overview pane, additional information, notes, files, tasks, tickets, and child records.
5. Connect pipelines only when the record needs stage movement or stage-based reporting.
6. Add quick actions for repeatable record operations that staff should run from the record header.
7. Publish portal or public access only after checking permissions, submission limits, and redirect behaviour.
8. Create a test record, update it, attach a file, add a note, and verify downstream workflows or reports.

Configuration options

Option	Use when	Notes
List view	Staff need to search, filter, bulk scan, and open records	Route: /objects/:objectName/list.
Record detail	Staff need one operational workspace per item	Route: /objects/:objectName/:itemId/view.
With inlines	Builders need embedded child or related views	Route: /objects/:objectName/:itemId/with-inlines.
Portal records	Customers should see their own data	Configure customer access and portal menu placement.
Public form	Anonymous submissions are needed	Use public object form settings and /form/<code>.
Static related panes	Notes, files, tasks, tickets, assets, bookings, or other system links should travel with the record	Enable the relevant object settings.

Operating notes

• Use human-readable labels; the object name becomes part of URLs, scripts, JQL namespaces, and menu shortcuts.
• Keep required fields limited to data needed at creation time; move review-only data into later sections.
• Saved filters should match real teams or stages, not temporary troubleshooting views.
• Record visibility is usually a combination of role permissions, object filters, menu access, and customer ownership.
• Bulk uploads should be tested with a small file first; Antly records a success and failure report for imports.
• If a record disappears from a user view, check object permissions, table filters, ownership filters, and portal flags before editing data.
• Use quick actions for staff-triggered operations and workflows for system-triggered operations.
• Put customer-facing record pages behind the portal unless the use case is intentionally anonymous.
• Avoid renaming object names after integrations are live because API callers and scripts may use the namespace.
• Review related tasks and tickets before deleting object records that have operational history.

For developers

Use the developer and reference pages when this configuration is read or changed by code, scripts, widgets, embeds, API clients, or webhooks.

• /developer/overview
• /developer/quickstart-api
• /reference/jql-overview
• /reference/namespaces
• /developer/data-hooks
• /developer/forms-uploads

Related links

• /guides/objects-overview
• /guides/form-schema
• /guides/associations-erd
• /guides/quick-actions
• /guides/portal-public-exposure