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.
This article will focus on the basics of how to work with the hierarchy in the Cirrus platform:
- Setting up a hierarchy
- Purpose of the hierarchy: defining groups and (sub)domains
- Examples of hierarchies and (sub)domain (root levels)
- Things to keep in mind when defining root levels aka (sub)domains
A typical hierarchy could look like this for example:
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:
- Title - name of the group
- 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'
- 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 or read 'Synchronisation Key' in our developer documentation.
Organisation ID - leave blank.
- Settings: 'Allow relationship with Scheduled assessments': Read 'Hierarchies and Clusters: ensuring scheduling by and for the correct people' to see what this box enables.
- After doing this and clicking 'Save' a new hierarchical level or group is created under the root level.
- 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.
Please note: for larger implementations we recommend to use an integration for management of users and the hierarchy.
Setting up the right Hierarchy for your organisation is a crucial step to align with your company's procedures and goals. A system administrator needs to define this in the Admin section of your environment.
Cirrus Assessment recommends to do this with one of our consultants.
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.
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
In Cirrus you can set so called 'root levels' flexibly. They mark what is referred to as a domain or subdomain. This represents (sub)unit of your organisation. Examples: they represent a faculty at an University, they may represent your delivery or test-centres. They can refer to your international operations versus you local operations et cetera.
Some important notes on using root-levels:
The UI shows which hierarchy levels are marked as an root level by marking them bold. Also see our 'Things to keep in mind when defining root levels aka (sub)domains'.
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.
- 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.