Workspace Administration
Organisation structure
Model organisations, departments, units, positions, teams, and groups.
Organisation structure
Organisation structure covers organisations, departments, units, positions, teams, groups, locations, reporting lines, and membership. 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: organisations, departments, units, positions, teams, groups, locations, reporting lines, and membership.
- Where users start: Organisation pages live under
/global-settings/company/organisations,/global-settings/company/departments,/global-settings/company/units, and/global-settings/company/offices. - Where administrators configure it: Teams and groups are managed at
/global-settings/company/teamsand/global-settings/company/groups; users are managed at/global-settings/users/list. - Runtime/detail surface: The structure is used for assignment, reporting, approvals, permissions, schedules, and module routing.
- Platform connections: Organisation data connects users, roles, teams, locations, tasks, approvals, HCM, attendance, and reports.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Organisation pages live under /global-settings/company/organisations, /global-settings/company/departments, /global-settings/company/units, and /global-settings/company/offices. | Day-to-day work and review. |
| Configuration | Teams and groups are managed at /global-settings/company/teams and /global-settings/company/groups; users are managed at /global-settings/users/list. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | The structure is used for assignment, reporting, approvals, permissions, schedules, and module routing. | 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: Organisation pages live under
/global-settings/company/organisations,/global-settings/company/departments,/global-settings/company/units, and/global-settings/company/offices. - Review the configuration route and permissions before changing live behaviour: Teams and groups are managed at
/global-settings/company/teamsand/global-settings/company/groups; users are managed at/global-settings/users/list. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Organisation, Department, and Unit first because they shape the rest of the rollout.
- Add Position and Team only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: The structure is used for assignment, reporting, approvals, permissions, schedules, and module routing.
- Check downstream connections after saving: Organisation data connects users, roles, teams, locations, tasks, approvals, HCM, attendance, and reports.
- 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 |
|---|---|---|
| Organisation | A tenant has multiple entities or divisions | Route: /global-settings/company/organisations. |
| Department | Reporting or ownership follows departments | Route: /global-settings/company/departments. |
| Unit | Departments need smaller operating units | Route: /global-settings/company/units. |
| Position | Approval or reporting follows job hierarchy | Route: /global-settings/company/offices. |
| Team | Work queues need shared ownership | Route: /global-settings/company/teams. |
| Group | Permissions or membership should be reusable | Route: /global-settings/company/groups. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Organisation and Department.
- 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.