Work Management
Projects
Use spaces, project pipelines, activities, dependencies, milestones, and timesheets.
Projects
Projects covers project lists, project detail pages, spaces, pipelines, activities, dependencies, milestones, deliverables, and timesheets. 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: project lists, project detail pages, spaces, pipelines, activities, dependencies, milestones, deliverables, and timesheets.
- Where users start: Project routes include
/projects,/projects/:id, and/projects/:projectId/activities/:activityId. - Where administrators configure it: The Projects tenant app appears from launchpad when enabled; project configuration uses the module app and its settings surfaces.
- Runtime/detail surface: Project detail pages organise activities, deliverables, owners, dependencies, milestones, and related work.
- Platform connections: Projects connect tasks, documents, finance, approvals, teams, timesheets, reports, and dashboards.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Project routes include /projects, /projects/:id, and /projects/:projectId/activities/:activityId. | Day-to-day work and review. |
| Configuration | The Projects tenant app appears from launchpad when enabled; project configuration uses the module app and its settings surfaces. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Project detail pages organise activities, deliverables, owners, dependencies, milestones, and related work. | 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: Project routes include
/projects,/projects/:id, and/projects/:projectId/activities/:activityId. - Review the configuration route and permissions before changing live behaviour: The Projects tenant app appears from launchpad when enabled; project configuration uses the module app and its settings surfaces.
- Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Project list, Project detail, and Activity detail first because they shape the rest of the rollout.
- Add Pipeline and Milestones only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Project detail pages organise activities, deliverables, owners, dependencies, milestones, and related work.
- Check downstream connections after saving: Projects connect tasks, documents, finance, approvals, teams, timesheets, reports, and dashboards.
- 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 |
|---|---|---|
| Project list | Teams need a portfolio view | Route: /projects. |
| Project detail | Teams need one project workspace | Route: /projects/:id. |
| Activity detail | Work needs a focused record | Route: /projects/:projectId/activities/:activityId. |
| Pipeline | Projects move through lifecycle stages | Configure stages where available. |
| Milestones | Management needs key dates | Use for commitments, not every task. |
| Deliverables | Outputs need tracking | Use activity deliverables. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Project list and Project detail.
- 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.