Workspace Administration
Menus & launchpad
Control the main menu, launchpad shortcuts, module tabs, and workspace navigation preferences.
Menus & launchpad
Menus & launchpad covers staff navigation: launchpad app tiles, main menus, page shortcuts, object shortcuts, mobile-enabled shortcuts, and settings entry points. 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: staff navigation: launchpad app tiles, main menus, page shortcuts, object shortcuts, mobile-enabled shortcuts, and settings entry points.
- Where users start: Users start at
/launchpad; the dark launchpad variant is/launchpad/dark. - Where administrators configure it: Admins manage apps from launchpad and configure pages, objects, and global settings from
/global-settings. - Runtime/detail surface: Launchpad tiles can point to enabled tenant apps or eligible shortcuts such as
/sites/:slugand/objects/:objectName/list. - Platform connections: Navigation connects tenant apps, user menus, page definitions, object lists, PWA shortcuts, and permissions.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Users start at /launchpad; the dark launchpad variant is /launchpad/dark. | Day-to-day work and review. |
| Configuration | Admins manage apps from launchpad and configure pages, objects, and global settings from /global-settings. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Launchpad tiles can point to enabled tenant apps or eligible shortcuts such as /sites/:slug and /objects/:objectName/list. | 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: Users start at
/launchpad; the dark launchpad variant is/launchpad/dark. - Review the configuration route and permissions before changing live behaviour: Admins manage apps from launchpad and configure pages, objects, and global settings from
/global-settings. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure App tile, Page shortcut, and Object shortcut first because they shape the rest of the rollout.
- Add Settings tile and Mobile flag only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Launchpad tiles can point to enabled tenant apps or eligible shortcuts such as
/sites/:slugand/objects/:objectName/list. - Check downstream connections after saving: Navigation connects tenant apps, user menus, page definitions, object lists, PWA shortcuts, 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 |
|---|---|---|
| App tile | A module should open from launchpad | Uses stable app keys such as tasks, tickets, projects, or inventory. |
| Page shortcut | A Sites page should open directly | Eligible shortcuts point to /sites/:slug. |
| Object shortcut | A dynamic object list should open directly | Eligible shortcuts point to /objects/:objectName/list. |
| Settings tile | Admins need tenant configuration | Route: /global-settings. |
| Mobile flag | A shortcut should appear in the PWA | Use only for responsive destinations. |
| Dark launchpad | Users prefer the alternate launchpad view | Route: /launchpad/dark. |
Operating notes
- Keep labels aligned with the words users see in the product, especially App tile and Page shortcut.
- 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.