Reports & Dashboards
Dashboards & dashlets
Build dashboards from dashlets, tiles, pie charts, line charts, bar charts, and workflow-aware widgets.
Dashboards & dashlets
Dashboards & dashlets covers visual management pages made of metric tiles, charts, tables, report widgets, and reusable dashlets. 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: visual management pages made of metric tiles, charts, tables, report widgets, and reusable dashlets.
- Where users start: Dashboard routes include
/dashboards,/dashboards/create-dashboard,/dashboards/:slug/view, and/dashboards/:slug/builder. - Where administrators configure it: Reusable page dashlets are configured at
/settings/pages/dashlets; dashboard dashlets are managed from the dashboard builder. - Runtime/detail surface: Dashboards combine charts, object counts, reports, module metrics, and page-builder widgets for daily monitoring.
- Platform connections: Dashboards connect reports, charts, pages, object data, permissions, date filters, and management workflows.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Dashboard routes include /dashboards, /dashboards/create-dashboard, /dashboards/:slug/view, and /dashboards/:slug/builder. | Day-to-day work and review. |
| Configuration | Reusable page dashlets are configured at /settings/pages/dashlets; dashboard dashlets are managed from the dashboard builder. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Dashboards combine charts, object counts, reports, module metrics, and page-builder widgets for daily monitoring. | 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: Dashboard routes include
/dashboards,/dashboards/create-dashboard,/dashboards/:slug/view, and/dashboards/:slug/builder. - Review the configuration route and permissions before changing live behaviour: Reusable page dashlets are configured at
/settings/pages/dashlets; dashboard dashlets are managed from the dashboard builder. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Dashboard, Builder, and Metric tile first because they shape the rest of the rollout.
- Add Chart dashlet and Table dashlet only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Dashboards combine charts, object counts, reports, module metrics, and page-builder widgets for daily monitoring.
- Check downstream connections after saving: Dashboards connect reports, charts, pages, object data, permissions, date filters, and management workflows.
- 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 |
|---|---|---|
| Dashboard | A team needs one monitoring page | Route: /dashboards/:slug/view. |
| Builder | Admins arrange tiles and layout | Route: /dashboards/:slug/builder. |
| Metric tile | One number should stand out | Use for SLA, open count, revenue, or overdue work. |
| Chart dashlet | Users need trend or comparison | Use bar, line, pie, or similar visual. |
| Table dashlet | Users need ranked or recent rows | Keep rows actionable. |
| Page dashlet | A reusable block belongs on a page | Configure at /settings/pages/dashlets. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Dashboard and Builder.
- 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.