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

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.

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.

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 Setting	Description
Organisation-Wide	Anyone belonging to the organisation can find and access the label.
Private	Only accessible by users or groups you have shared the label with.
Inherit	Use 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 Level	Can See Label	Can Edit Activities	Can Edit Labels
View
Edit
Owner

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.

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.

Approach	Considerations
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.