Organizational Hierarchy
Requires. Organizational Hierarchy.
Heads up. This area is only available to companies that already have people placed in the hierarchy. Org Structure supersedes it and is the place to build a new structure, so companies that never used the hierarchy won't see this card and its pages return "not found". If you need it turned back on, contact SecurityTrax support.
The Organizational Hierarchy area is where your company models its management structure — who reports to whom, and which projects or committees (working groups) each person is on. The hierarchy matters beyond HR record-keeping: it feeds the Managers filter on the Tickets queue, drives the Hierarchy variant of payroll functions (manager overrides on rep sales), and can be used by some permission inheritance rules.
Two distinct sub-areas live here:
- The tree — the main reporting-chain visualization.
- Working Groups — cross-cutting groupings that don't fit the reporting tree.
Role labels moved out: see User Titles, which is now its own area with its own permission and stays available whether or not you use this hierarchy.
The heading is "Organizational Hierarchy".
Getting here
- From the Admin index, click Organizational Hierarchy.
- Or navigate directly to
https://portal.securitytrax.com/{your-company}/admin/organizational-hierarchy.
The main tree view
Routes: admin.organizational-hierarchy.index (default tree), admin.organizational-hierarchy.show (specific tree ID).
Shows every user grouped by their reporting chain. Expand and collapse branches with chevrons. Click a user node to jump to their Users admin record.
Hover over a user's card to reveal its action buttons — Add Direct Report, Move Entry (re-parent them under a different manager), Swap Entry, and Delete Entry. Each opens a picker so you choose the other user; use Add top-level entry above the tree to start a new root. SecurityTrax audits every change to the hierarchy.
Focus on one person
Big trees are easier to read one branch at a time. Use the Focus on User dropdown above the tree to show just that person plus everyone beneath them — their direct reports, their reports' reports, and so on. Click Reset to return to the full tree. (The Focus controls appear for users who can edit the hierarchy.)
When you're focused on someone who reports to a manager, an ↑ {manager name} button appears just above their card. Click it to move the focus up to that manager; keep clicking to walk all the way up the chain. The button disappears once you reach the top of the tree.
What the tree drives
- Tickets manager filter. Selecting a manager narrows the ticket list to every user in that manager's subtree.
- Payroll hierarchy functions. A manager earning an override on their team's sales depends on the tree to know who's "their team."
- Permission inheritance (optional, company-configurable).
A company can also keep more than one hierarchy — the main reporting tree plus any number of working groups (covered below), each its own tree.
Working Groups
Routes: admin.organizational-hierarchy.working-groups.*.
A working group is a separate hierarchy — its own tree, alongside the main reporting tree — for groupings that cut across the reporting chain: project teams, committees, on-call rotations, regional pods. You name the group, then build its membership in its own tree view, so a person can sit in any number of working groups regardless of where they land in the main tree.
The Working Groups list
| Column | What it shows |
|---|---|
| ID | The group's identifier. |
| Name | Group name. Click it to edit the name and description; click View next to it to open the group's tree and manage members. |
| Description | Optional purpose statement. |
| Members | Count of people in the group. |
Click New Working Group to create one.
Working Group form
| Field | Required? | Type | Validation | Notes |
|---|---|---|---|---|
| Name | Yes | Text | 1–100 characters | |
| Description | No | Text | — | Internal purpose statement. |
Save to commit. To add or arrange members, open the group with its View link and use the per-card action buttons the same way you do on the main tree — each member can also be given an optional role label on their card.
Step-by-step: onboarding a new district manager
- First, make sure their User record exists.
- Open the tree view. Find the user. Hover their card, click Move Entry, and pick the regional manager they report to.
- Go to User Titles. If "District Manager" doesn't exist, create it.
- Open the user's record from Users. Set their title to "District Manager" on the Edit sub-tab.
- (Optional) Add them to relevant working groups — sales leadership committee, regional ops, etc.
Non-obvious behaviors
- Moving a user in the tree is instant and cascading. Their whole subtree moves with them. Be careful when restructuring — you may accidentally reassign hundreds of users.
- Working groups don't grant permissions directly. They're a labeling mechanism. Some features (payroll, filters, notifications) read working-group membership, but the UDF-like grant doesn't flow automatically.
Related
- Org Structure — the newer sales-team structure that supersedes this one.
- Users — individual user records; the tree attaches these.
- Permissions — what users can do, separate from what the tree says.
- User Titles — role labels shown on each card, managed separately.
- Payroll Admin Overview — how users earn, separate from titles.