• 01 Apr 2022
  • 5 Minutes to read
  • Contributors
  • Dark
  • PDF


  • Dark
  • PDF

Article Summary

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 \ 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.

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.

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

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:

  • Setting root-levels is vital for larger organisations, failing to do so users will inevitably see all groups including ones they should not have access to!
  • Root-levels  can be one level or or a branch of levels within your overall hierarchy.
  • Marking a group as a root-level makes it the new root level for the users belonging to this hierarchy level - except for Admin users.
  • The purpose of selecting a hierarchy group as root-level is to limit what groups of users an author/scheduler/etc can select when

    • Searching and adding candidates to a schedule
    • Search and adding invigilators to a schedule
    • Searching markers/moderators and adding them
    • Searching users to share collections, assessments and media elements

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'.


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.


Was this article helpful?

What's Next