Reports

Reports covers reusable report definitions, parameters, report history, exports, background delivery, and report studio. 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: reusable report definitions, parameters, report history, exports, background delivery, and report studio.
• Where users start: Standalone reports live at /settings/reports/list; add and edit routes include /settings/reports/add and /settings/reports/:reportId/edit.
• Where administrators configure it: Object reports live at /settings/objects/:objectId/reports/list and use object report studio routes.
• Runtime/detail surface: Reports are used for repeatable analysis, exports, dashboards, charts, and management reviews.
• Platform connections: Reports connect namespaces, field selection, filters, permissions, object schema, modules, and scheduled operations.

Where it lives

Area	Path or surface	Use it for
User surface	Standalone reports live at /settings/reports/list; add and edit routes include /settings/reports/add and /settings/reports/:reportId/edit.	Day-to-day work and review.
Configuration	Object reports live at /settings/objects/:objectId/reports/list and use object report studio routes.	Setup, permissions, routing, labels, and behaviour.
Runtime/detail	Reports are used for repeatable analysis, exports, dashboards, charts, and management reviews.	Testing the live experience users actually see.

Configure it

1. Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
2. Open the owning product route: Standalone reports live at /settings/reports/list; add and edit routes include /settings/reports/add and /settings/reports/:reportId/edit.
3. Review the configuration route and permissions before changing live behaviour: Object reports live at /settings/objects/:objectId/reports/list and use object report studio routes.
4. Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
5. Configure Standalone report, Object report, and Parameterized report first because they shape the rest of the rollout.
6. Add Background delivery and Export only after the core path works with sample data.
7. Test the runtime surface as a restricted user, not only as a superadmin: Reports are used for repeatable analysis, exports, dashboards, charts, and management reviews.
8. Check downstream connections after saving: Reports connect namespaces, field selection, filters, permissions, object schema, modules, and scheduled operations.
9. Record the owner, rollout date, and support path for the configuration.
10. Review the first week of activity and remove any option that users do not understand or need.

Configuration options

Option	Use when	Notes
Standalone report	Cross-workspace or module report	Route: /settings/reports/list.
Object report	Report belongs to one object	Route: /settings/objects/:objectId/reports/list.
Parameterized report	Users choose dates, status, team, or location	Keep labels clear.
Background delivery	Report takes time or should be distributed	Check history and recipients.
Export	Users need offline analysis	Confirm permission and data sensitivity.
Dashboard source	A report should power a visual	Pair with charts or dashlets.

Operating notes

• Keep labels aligned with the words users see in the product, especially Standalone report and Object report.
• 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/data-hooks
• /reference/reports-dashboards
• /reference/filters-and-queries
• /reference/field-selection

Related links

• /guides/object-reports
• /guides/charts
• /guides/dashboards-dashlets
• /guides/records