Team security

Team security level determines which users are authorized to view information for and about specified employees, such as timesheets. After users and employees have been created, you need to set up roles and teams.

Team security is set up hierarchically. These are the hierarchical relationships within the model:

  • The Security Model always starts at the top of the hierarchy, called the Root. If authorized, users who belong to the Root team can view employee information within the entire structure.
  • Team users can view employees that reside on the user’s current team and downward. For example, a manager of a store can view all the employees that are assigned to his store. If any sub-stores, such as kiosk, exist further down in the hierarchy, the manager will also be able to view those employees.
  • Team users cannot view employee information in other teams at the same level. For example, the manager of Store A cannot view the employees of Store B.


This table shows how each Team Type associates with a Team Hierarchy Type, which influences its placement within the security model and the visibility it grants.
Team Type Description Team Hierarchy Type
CREWS A group of people who work together. None
DEPARTMENT A logical grouping of people. None
DRIVER A logical grouping of people. None
HRORGUNIT A logical grouping of people with different hierarchy. None
NULL No specific type. None
Note: All current team types have None set as their Team Hierarchy Type. As a result, the team types do not define or follow a specific hierarchy structure, relying instead on manual configuration within team relationships.

Specifying a Team Hierarchy Type automates and standardizes hierarchical relationships across multiple teams, such as automatically defining parent-child relationships based on organizational structures or department models. Leaving the Team Hierarchy Type as None requires explicit configuration of all hierarchical relationships when teams are created and assigned.

When a Team Hierarchy Type is specified, such as HR Org Unit or Supervisor, strict parent-child relationship rules are enforced within the same hierarchy type. Teams with mismatched hierarchy types cannot be created, as errors are triggered during validation. If the Team Hierarchy Type is set to None, no automatic hierarchy rules apply, and relationships must be manually configured.

When dual team hierarchies are supported, these validation rules apply:

  • HR Org Unit: The team can only have HR Org Unit as the parent team type.
  • Supervisor: The team can only have Supervisor as the parent team type.

If a team is created with a parent of a mismatched hierarchy type, an error message is displayed:

A team of type '{child_team_type_hierarchy}' can only have a parent team of the same type. You selected a parent team of type '{parent_team_type_hierarchy}'.

Defining a Team Hierarchy Type allows organizations to automate and standardize team structures, promoting consistency across departments and hierarchies.

After you have set up the appropriate users, you can start setting up team-level security. The setup requires you to:

  • Create employee roles.
  • Create teams.
  • Assign users to teams and roles.
  • Assign employees to teams.