Delegates

A Delegate is a person that is granted privileges specific to one or more teams. For example, a supervisor can be made a Delegate of teams that they need to supervise and granted supervisor assessment privileges for those teams. As another example, if a person is generally not allowed to view other people in the system however they need to be able to view people in their own team, they can be made a Delegate of their team with view privileges.

Video tutorial: Configuring Permissions in Skills Base (2/2) - Delegates

The Delegates system is designed for maximum flexibility with the least amount of administrative overhead. This is a challenging combination of characteristics to achieve and so this topic is slightly more advanced than other more intuitive aspects of the system.


What makes a person a Delegate?

To be able to be a team Delegate, a person must have at least one privilege within their assigned Security Group granted with the "Delegated" scope. By granting at least one privilege with the "Delegated" scope, the Security Group becomes a "Delegate" Security Group, meaning privileges can change based on team assignment.


How Delegates are assigned to teams

Delegates are assigned to teams based on Team configuration. When editing a team, the "Delegates" setting provides three options to choose from:

  • Delegates in this team - When this option is selected the following people will be able to view, edit, and/or assess (based on Security Group privileges) people within the team:
    • People directly within the team (excluding its sub-teams) with Security Group privileges granted with the "Delegated" scope.
    • Delegates from all parent teams
    • Any person in the system with Security Group privileges granted with the "all" scope (including the "Administrator" Security Group).
  • Specific Delegates - When this option is selected the following people will be able to view, edit, and/or assess (based on Security Group privileges) people within the team:
    • People you specifically identify (who must have Security Group privileges granted with the "delegated" scope).
    • Delegates from all parent teams
    • Any person in the system with Security Group privileges granted with the "all" scope (including the "Administrator" Security Group).


In general, it is recommended to aim for the default option of Delegates in this team for ease of administration and in order to reduce complexity. Naturally there will be cases for deviating from this setting however in the majority of cases where teams in Skills Base have been configured to mirror an organizational hierarchy, this setting should generally suffice for most requirements.


Configuring Delegate permissions

Delegate permissions are configured via Security Groups. Any Security Group that has at least one privilege granted with the "Delegated" scope is considered a "Delegate Security Group" with that privilege defining the permissions that the Delegate will carry to each assigned team.


Example 1: Enabling a supervisor the ability to assess their own team

In this example we want a supervisor to be able to view all people in the system regardless of team, but have the ability to assess members of their own team.

  1. Create a Security Group named "Supervisor"
  2. Grant the People > View privilege with "All" scope.
  3. Grant the People > Assess privilege with "Delegated" scope.
  4. Edit the Supervisor's team and ensure the "Delegates" option is set to "Delegates in this team"
  5. Assign the "Supervisor" Security Group to all relevant supervisors (The bulk-edit feature in the People Directory is a good option for accomplishing this in one step).


Because the supervisor is granted People > Assess with "Delegated" scope, and they have been assigned as a Delegate of their own team the People > Assess privilege will apply to their team but not the others of which the supervisor is not a Delegate. Note that this permission will flow through to any/all sub-teams and so the supervisor will be granted assessment privileges for all teams down the hierarchy starting from the supervisor's assigned team. There is no way to prevent this cascading of permissions.


Example 2: Preventing employees from viewing people outside their own team

In this example we would like to allow employees the ability to view their team members, but prevent them from viewing people outside of their team.

  1. Create a Security Group named "Employee"
  2. Grant the People > View privilege with "Delegated" scope.
  3. Edit each team in the system, ensuring the "Delegates" option is set to "Delegates in this team"
  4. Assign the "Employee" Security Group to all employees (The bulk-edit feature in the People Directory is a good option for accomplishing this in one step).


Because employees have been granted People > View with "Delegated" scope, and all teams are configured to look within their own membership for Delegates, employees will be able to view people within their own team, but not other teams. Note that this permission flows through to any/all sub-teams and so employees will be granted viewing privileges for all teams down the hierarchy starting from their assigned team. There is no way to prevent this cascading of permissions.