# Organising Activities The **Labels** directory on the right-hand side of the **Activities** screen can be used to organise your content into a nested folder structure. This can help to keep your activities list tidy so that you can find resources more quickly in the future. It can also be used to restrict access to certain activities by marking the label as *private* and restricting who it's *shared* with. ### Label Structure What labels you decide to create and how you organise your content is entirely up to you and what makes the most sense for your organisation. However, there are two patterns we see used most commonly amongst our users. #### Org-Centric Structure Mirroring your label structure with your organisational hierarchy helps to align content with the teams responsible for managing that content. This could be done by Department or geographical area, for example, your labels could look like the following: * Asia Pacific * Administration * Information Technology * Sales / Marketing * North America * Administration * Information Technology * Sales / Marketing When it comes to sharing, this makes it easy to share labels with the teams they belong to so they can manage their own content and resources. {% hint style="info" %} **Hint:** An activity can belong to multiple labels. This means that IT training material that might be used across regions can be labelled as **Asia Pacific / Information Technology** as well as **North America / Information Technology** to allow for shared visibility and ownership. {% endhint %} #### Content-Centric Structure When your content is more centrally-managed by a small team, an alternative structure based on function might prove more beneficial. For example, if your HR team manages the content for the entire organisation, you could assign that content to labels based on how the content is used. For example: * Onboarding * Induction * Learning * Competencies * Compliance * Technical Skills * Performance Management * Assessments * Goal-Setting Applying labels this way can help to organise content based on how it's used and permissions can be applied so that members of the team who manage certain aspects of the employee lifecycle can take ownership of that content. {% hint style="info" %} Remember, there's no right or wrong way to organise your content and it's entirely valid to use a combination of the above (or something entirely different altogether!). Because activities can belong to many labels, you can use multiple intersecting governance strategies to manage access appropriately. {% endhint %} ### Controlling Label Permissions Organising your activities into a series of labels is a good hygiene practice but it also has the practical benefit of enabling strict management of who is able to administer what content. By default all labels are considered **organisation-wide** unless set to private – this means anyone who has admin privileges to the **Activities** screen will see all labels and activities. You can change this behaviour by hovering over a label, clicking the 3 dots that appear and selecting **Edit**.
The **Visibility** setting controls who is able to see the label and its contents and can be one of the following options:
Visibility SettingDescription
Organisation-WideAnyone belonging to the organisation can find and access the label.
PrivateOnly accessible by users or groups you have shared the label with.
InheritUse the permissions from the label that contains this one.
**Inherit** is the default setting for nested labels which means the label's visibility will be controlled by the label that contains it. This means that permission changes at the top-level will generally flow down to any labels underneath it, unless those labels themselves have been configured differently. When set to **private**, a table will appear allowing you to define who should have access to that label. You can add users individually or add a user group to grant permissions to a wider range of users at once. #### Access Levels The permissions table also allows setting an *Access Level* for users or groups you add to the label. This means different users can be granted visibility over a label but with different levels of permissions. The below table shows what actions are permitted by different access levels
Access LevelCan See LabelCan Edit ActivitiesCan Edit Labels
Viewtruefalsefalse
Edittruetruefalse
Ownertruetruetrue
{% hint style="info" %} It's worth noting that while an *Editor* can create or edit any activity underneath that label, only an *Owner* can edit the permissions on the label or create sublabels under the label. {% endhint %} #### Open or Closed Access? A decision you will need to make early on is whether you want all administrators to access everything by default (*open access*) or whether they won't be able to see anything will need to be added to labels to access content (*closed access*). The below table outlines the considerations with each of these approaches.
ApproachConsiderations
Open Access
  • By default, your label directory will be set as Organisation-wide and everyone will have access to everything.
  • To restrict access, you will need to mark certain labels and their descendants as private.
  • This approach is suited to organisations with small numbers of admins who have access to the majority of content.
  • Some content may be deemed sensitive and can be further restricted to specific users or groups.
Closed Access
  • The label directory will need to be set to Private to restrict access to all activities. Only users added to the label directory permission will have access to all content.
  • Labels will need to be set to Private with users added to those labels to grant them permission to see and edit content.
  • This approach is suited to organisations with large numbers of admins who should only be able to access small amounts of content.
### Roles It's important to understand how **Roles** overlap with **Label** permissions. The difference between these can generally be summarised in two short points: * **Roles** are the master control that grant a user access to specific platform functions or screens. * **Labels** further restrict a user's access to activities within each of those platform functions. Labels cannot grant more permissions than are allowed by their system *Role*. For example, if a user has a **Role** with *read-only* access to the *Activities* screen then that privilege cannot be elevated by adding them to a **Label** and giving them *Edit* or *Owner* permissions. The rationale for this is that **Roles** provide a centralised location for super admins to provide hard restrictions on other user's access levels. Labels can, however, be used to further restrict someone's access to activities. For example, if a user belongs to a **Role** that grants them access to *Dashboards*, then they will only see activities on that Dashboard for labels that they also have access to.