Charts

Charts covers visualisations for dashboards, pages, reports, object reports, page-builder data widgets, and management views. 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: visualisations for dashboards, pages, reports, object reports, page-builder data widgets, and management views.
• Where users start: Dashboard chart dashlets are edited from dashboard builder routes such as /dashboards/:slug/builder.
• Where administrators configure it: Reusable page dashlets live at /settings/pages/dashlets; reports live at /settings/reports/list; object reports live under object settings.
• Runtime/detail surface: Charts display counts, totals, trends, comparisons, backlog, conversion, and financial or operational metrics.
• Platform connections: Charts connect JQL filters, report definitions, page-builder widgets, object fields, permissions, and dashboards.

Where it lives

Area	Path or surface	Use it for
User surface	Dashboard chart dashlets are edited from dashboard builder routes such as /dashboards/:slug/builder.	Day-to-day work and review.
Configuration	Reusable page dashlets live at /settings/pages/dashlets; reports live at /settings/reports/list; object reports live under object settings.	Setup, permissions, routing, labels, and behaviour.
Runtime/detail	Charts display counts, totals, trends, comparisons, backlog, conversion, and financial or operational metrics.	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: Dashboard chart dashlets are edited from dashboard builder routes such as /dashboards/:slug/builder.
3. Review the configuration route and permissions before changing live behaviour: Reusable page dashlets live at /settings/pages/dashlets; reports live at /settings/reports/list; object reports live under object settings.
4. Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
5. Configure Pie/donut, Bar, and Line first because they shape the rest of the rollout.
6. Add Metric tile and Table widget only after the core path works with sample data.
7. Test the runtime surface as a restricted user, not only as a superadmin: Charts display counts, totals, trends, comparisons, backlog, conversion, and financial or operational metrics.
8. Check downstream connections after saving: Charts connect JQL filters, report definitions, page-builder widgets, object fields, permissions, and dashboards.
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
Pie/donut	Show part-to-whole distribution	Use for categories or statuses with few values.
Bar	Compare groups	Use for teams, products, stages, or categories.
Line	Show trends over time	Use with date fields and stable intervals.
Metric tile	Show one headline value	Pair with a drill-down link.
Table widget	Users need ranked values or detail rows	Keep columns narrow.
Report-backed chart	Finance or operations need repeatable definitions	Build from Reports.

Operating notes

• Keep labels aligned with the words users see in the product, especially Pie/donut and Bar.
• 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
• /developer/runtime-overview
• /reference/reports-dashboards
• /reference/filters-and-queries

Related links

• /guides/dashboards-dashlets
• /guides/reports
• /guides/object-reports
• /guides/page-builder-v3