Pages & Sites
Pages overview
Create staff, portal, and public pages that surface dashboards, records, widgets, and custom apps.
Pages overview
Pages overview covers Sites pages, Page Builder V3, Page Builder V4, dashlets, widgets, portal pages, staff home pages, and custom page navigation. 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: Sites pages, Page Builder V3, Page Builder V4, dashlets, widgets, portal pages, staff home pages, and custom page navigation.
- Where users start: Staff pages render under
/sites/:page; the default home route is/sites/home. - Where administrators configure it: Page definitions are managed at
/settings/pages/pages; dashlets at/settings/pages/dashlets; portal menus at/settings/pages/customer-portal-menu. - Runtime/detail surface: Pages surface dashboards, object data, forms, charts, reports, tabs, Iris chat, and module experiences.
- Platform connections: Pages connect visual builders, React runtime blocks, JQL data hooks, widgets, menus, portal navigation, and permissions.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Staff pages render under /sites/:page; the default home route is /sites/home. | Day-to-day work and review. |
| Configuration | Page definitions are managed at /settings/pages/pages; dashlets at /settings/pages/dashlets; portal menus at /settings/pages/customer-portal-menu. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Pages surface dashboards, object data, forms, charts, reports, tabs, Iris chat, and module experiences. | 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: Staff pages render under
/sites/:page; the default home route is/sites/home. - Review the configuration route and permissions before changing live behaviour: Page definitions are managed at
/settings/pages/pages; dashlets at/settings/pages/dashlets; portal menus at/settings/pages/customer-portal-menu. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Sites page, Pages settings, and Dashlets first because they shape the rest of the rollout.
- Add Portal menu and Page Builder V3 only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Pages surface dashboards, object data, forms, charts, reports, tabs, Iris chat, and module experiences.
- Check downstream connections after saving: Pages connect visual builders, React runtime blocks, JQL data hooks, widgets, menus, portal navigation, and permissions.
- 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 |
|---|---|---|
| Sites page | Staff need a workspace page | Route: /sites/:page. |
| Pages settings | Admins create and edit pages | Route: /settings/pages/pages. |
| Dashlets | Reusable dashboard/page widgets | Route: /settings/pages/dashlets. |
| Portal menu | Customers need navigation to pages | Route: /settings/pages/customer-portal-menu. |
| Page Builder V3 | Visual block editing is preferred | Good for controlled layouts. |
| Page Builder V4 | Iris-first generation is preferred | Good for rapid page creation. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Sites page and Pages settings.
- 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.