Hierarchies

Setting up and using Hierarchies in Cirrus

Hierarchies in the Cirrus platform is a way of organising the users. The hierarchy contains a main root level and one or more sub-hierarchies. By adding users to hierarchies you have a convenient way of filtering users. Like any hierarchy, you can build a tree with branches that represent groups and organisational units. How to do this is fully flexible and up to you. What is crucial is that you can and should limit what groups of users can see and can do.

Setting up a hierarchy

A typical hierarchy could look like this for example:

CeA
CeA \ Test center 1
CeA \ Test center 1 \ Cohort A
CeA \ Test center 1 \ Cohort B

Setting up and maintaining your hierarchy can easily be done manually via Admin > Hierarchies 

• Click on '+' to create a hierarchy on a specific level
• At the right side of the page a screen opens were you set the Title of the hierarchy-level (=name of the group) and several other options:

1. Title - name of the group
2. Root level - 'Define this hierarchy as a new root level': By checking this box you limit what users in part of the tree can see. It is used to define strict clusters of sub-groups or (sub)domains within your setup. Read 'Defining groups and (sub)domains within your Hierarchy'
3. Synchronisation Key [optional]: this is used for synchronising hierarchies when importing through an integration or webservice. This unique identifier will recognise any existing hierarchy sync ID's and if they already exist, the import will not create duplicate hierarchies. It is used in integrations - leave blank
   Organisation ID - leave blank.
4. Settings: 'Allow relationship with Scheduled assessments'
5. After doing this and clicking 'Save' a new hierarchical level or group is created under the root level.
6. You can build your hierarchical tree by simply dragging and dropping all groups in the right order.
   Tip: If you have a lot of hierarchies click on the '-' to fold in groups of hierarchy levels (it becomes a '+'). Also you can drag and drop it several times, 'stopping' along the way to gradually move up long lists.

Tip: in some cases, if you quickly need to setup a slightly bigger hierarchy manually, you can import users with the right sub-hierarchy defined. This will create the sublevels upon import - see the article about importing users into Cirrus.

Defining groups and (sub)domains within your Hierarchy

The hierarchy or hierarchical tree helps you to structure what users can see and do (together with their Role and profile settings of course). It can also be a great help to schedule for groups of users or narrowing down while searching for users.

• A hierarchy or hierarchical level can be considered a group of users.
• A domain or subdomain is a part of your overall hierarchy or complete tree of groups

Examples of hierarchies and (sub)domain (root levels)

Let’s look at some examples:

University of St Alban (root)
  - Faculty of Economics and Management (defined as root-level)
- Institute for Business Economics
    - Micro Economics (department)

Faculty of Humanities
- Institute for History (defined as root-level)
- Industrial Revolution (department)
    - Age of Enlightenment (department)

  - Centre for Linguistics (defined as root-level)

Defining root levels in this example ensures that a scheduler in a group belonging to the for the faculty of Economics and Management will only see the levels / groups below that branch.

Things to keep in mind when defining root levels aka (sub)domains

• The setting of root levels can only be done in separate branches in your hierarchy. In other words, taking a look at our example above: it is not possible to set a department as a root-level if you have already selected the higher level branch (Faculty) as a root-level. 
• However, it is possible to select other parallel hierarchy levels as root levels. So it is possible to select Faculty 1 and Faculty 2 as root levels.
• The highest level (the site's root level) (University of St Albans in our example) cannot be set as a root-level.
• If a user is added to Micro Economics (department), then the faculty of Economics and Management will be the new root level for this user. He will not be able to view other levels under the site's root level (the highest level in your hierarchy tree). So the user will not have access to the level 'Faculty of humanities'.
• System administrators are not affected by set root levels setup. They can always see all groups / levels / branches.

• Never add users directly to the highest level (site root) (even if that user should be able to see everyone in the site this is considered bad practice. This will inevitably lead to users seeing too much or people adding the wrong candidates or colleagues to an assessment or schedule for example.

• All core hierarchies (like departments, colleges, schools etc) should become root-levels, meaning they should be marked as root levels.

• All users in the site should belong to at least one root-level or a group under a root-level.