« Return to the main support page

Configuring Permissions

Overview

Permissions in Skills Base are controlled via a combination of the following mechanisms:

  1. Security Groups
  2. Delegates (optional)


Security Groups

Security Groups define the privileges that a person is granted. These privileges include the ability to view, edit and delete different record types, and the ability to access parts of the system. Anyone that can log in to Skills Base must be assigned a Security Group, and a person can only have one Security Group at any one time.

Video tutorial: Configuring Permissions in Skills Base (1/2) - Security Groups

By default Skills Base comes with the following pre-defined Security Groups for convenience:

  1. Administrator - Members of this group will have unrestricted access to all features, data and privileges across your instance.
  2. Supervisor - This group is pre-configured to provide members access to conduct supervisor assessments of teams of people for which they are a Delegate (see Delegates), as well as some additional privileges for those teams.
  3. General Staff - This group has been pre-configured to allow members to view all data in the system without the ability to make changes.


All Security Groups allow self-assessments to be undertaken.


Modifying Security Groups

Administrators have the ability to not only edit the pre-defined Security Groups, but to also create new ones. There is no limit to the number of Security Groups you can have, although the fewer there are the less overhead there will be in managing them.

Note that the "Administrator" Security Group permanently has full access and cannot be edited or deleted.

To add or edit a Security Group, you must be a member of the "Administrator" Security Group.


Editing a Security Group

  1. Click the "Admin -> Security Groups" menu item
  2. Click the "Edit" button corresponding to the desired Security Group
  3. Make the required changes and click "Save"


Creating a new Security Group

  1. Click the "Admin -> Security Groups" menu item
  2. Click the "Add a new Security Group" button
  3. Provide a name, and optionally a description
  4. Set the desired privileges
  5. Click "Save"


Copying an existing Security Group

  1. Click the "Admin -> Security Groups" menu item
  2. Click the downward facing arrow next to the "Edit" button on the corresponding Security Group that you would like to copy
  3. Click "Copy"
  4. Update the name, and optionally the description
  5. Make the required permission changes and click "Save"


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).
  • All 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:
    • All people in the system with Security Group privileges granted with the "delegated" scope (regardless of team assignment).
    • 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.


Auditing Permissions

Permissions can be audited in four ways:

  1. By editing a Security Group and reviewing the granted privileges
  2. By Temporarily assuming a different Security Group
  3. By running the "Permissions Audit" report (Reporting -> Reports -> Permissions Audit) for teams. This will show a list of all teams in the system along with all of the people that have permissions relating to them.
  4. By running the "Permissions Audit" report (Reporting -> Reports -> Permissions Audit) for a specific person. This will show the privileges a person has in relation to each team in the system.