Managing Managers and Hierarchy - User vs Departmental Model

Background

AMS now includes a configurable option that controls how manager visibility works within the Tasks area.

Typically, AMS is designed to use a Department-based model, where managers can see tasks belonging to their department and any child departments beneath them.

A new User-based model has been introduced to provide greater flexibility. This allows visibility to follow person-to-person reporting lines instead of department hierarchy.

This article explains both models, how they differ, and how to switch between them.

Figure 1 – Organisational hierarchy used in this article.

Department Model (Default Setting)

In the Department model, visibility is hierarchical.

Managers can see:

• All tasks assigned within their own department.
• Tasks belonging to users in child departments below them.

This mirrors a typical organisational structure, such as watches, stations, or districts.

Example

• Bob, based in Western District, can see tasks for everyone below him.
• Jim, in the same structure, can also view his team’s tasks (Red and Blue).
• As well as his own team by default, if Harry is additionally assigned as the manager of Blue Shift, he can see Ellie and Sally’s tasks too, even though they belong to another department.

User Model (New Option)

The User model links visibility to direct manager relationships rather than departmental hierarchy.

Each user can have an assigned Manager. These managers are not bound by the department hierarchy model. In this example, there is nothing to prevent Ellie from being Harry’s manager.

Managers can then see:

• Tasks for each user they manage directly.
• Tasks for any users further down that chain (for example, a “manager of a manager”).

Example

• Harry manages Jim.
• Jim manages Tom.
• Therefore, Harry can see tasks for both Jim and Tom.
• However, Harry cannot see Connor’s tasks, because Connor is not part of that user chain.

IMPORTANT

This structure is separate from the Departmental hierarchy. When enabled, users will not have access to their department or its child departments’ tasks.


If no user managers are defined, users will only see tasks they have been assigned or authored.

How It Works Technically

When the feature is turned off, AMS behaves as before, using the Department model. No queries are affected and visibility remains hierarchical. When enabled, AMS switches to the User model logic.

Queries are adjusted to return only:

• Tasks where the logged-in user is the assignee or author.
• Tasks belonging to users they manage, directly or indirectly, according to the external hierarchical structure set via API or employee linkage.

For example, when Employee A is set as the manager of Employee B, Employee A can immediately see Employee B’s tasks. If Employee B is also the manager of Employee C, Employee A can see Employee C’s tasks as well, forming a visible reporting chain.

Configuration

To configure this setting:

1. Navigate to Settings → Permissions & Visibility → Manager Mode.
2. Choose one of the following options:
   • Department Model – hierarchical visibility (default).
   • User Model – person-to-person visibility.
3. Save your changes.

This setting applies system-wide but can be toggled on or off safely at any time. No existing data or task assignments are modified; only the visibility logic changes.

Configuration is only available to certain accounts. If you do not have access to your company preferences, please contact support.

API Management

You can manage the same hierarchy structure through the AMS API.

Endpoint

PATCH /v2/admin/users/{userId}/external-hierarchy

This endpoint allows synchronisation of external employee and manager IDs from HR systems or other external databases.

Both values are optional and accept alphanumeric free text, allowing you to use existing references already defined in other user management tools.

How It Works

• The external_employee_id uniquely identifies the user.
• The external_manager_id links that user to their manager by referencing another employee’s ID.
• These IDs can be imported, updated, or synchronised from HR, payroll, or identity systems, ensuring AMS remains aligned with your organisation’s existing user structures.

Once applied, AMS uses these external references to determine who can see whose tasks when the User Model is active.