What changes with Manager Hierarchy

Manager Hierarchy uses one simple rule: you need access to something before you can use it. Folders are shared with specific teams, sub-folders and bots inherit those teams, and Learning Modules now follow the same model.

This keeps every team on a module working from content they can all actually see, so nothing breaks silently. Everything below cascades from one choice: who a module is for.

Prerequisites

• Must be an Admin, or a Member+ with team access

• Must have Manager Hierarchies enabled for the workspace

• Refer to How to: Configure Visibility Settings and How to: Manage Folder and Bot Access to understand how access and visibility work.

Step 1: Choose who the module is for

When you create a module, you pick who it is for, the same way you do for a folder:

Under Selected teams you can only pick teams you have access to, which is your team and its sub-teams.

Every other rule below follows from this choice.

Which Bots you Can Add

Every bot in the module must be visible to all of the module's teams.

If a module is shared with two teams and a bot is only visible to one of them, that bot cannot be added. You will see it marked Not available to all teams, with a note that it is outside the module's teams. To use it, either share the bot's folder with those teams or change the module's teams.

Call blitz

When you set up a call blitz, folders that are not shared with all of the module's teams are unavailable. The same rule applies: the call blitz has to work for every team on the module.

Assignment

You can assign the module only to its own teams.

For ex. If the module is shared with Atul's team and the engineering team, those are the only teams you can assign it to.

Analytics

Admins and Member+ users with partial access see analytics only for the teams within their access scope. A Member+ acting as a program admin or player coach sees progress for the teams they cover, not the whole org.

A label showing the current scope, like the "showing calls for [team]" label on Call History, is coming to Learning Module analytics. The scoping itself already applies.

Key Edge cases to know

Each of these has a built-in warning, so nothing changes silently.

Removing a team from a live module

If you remove a team from a module that has an active assignment, a warning pop-up appears first. Any reps on the removed team are taken off that assignment. If the change also leaves a bot that not all teams can access, the related task is suspended. Confirm to proceed.

Changing folder permissions

Folder access and Learning Modules are linked, because a module's bots live in folders. If you change who a folder is for in Folder Settings and that would pull access to bots a module depends on, a banner appears:

This change affects active training. Bots in this folder are used in [N] learning module(s). Removing a team suspends those tasks for everyone on those modules until access is restored. Completed work is kept.

What a suspended task means

A module needs every bot visible to all of its teams. When a folder or module change breaks that, the task is suspended rather than deleted.

In the admin view the task shows as suspended, and hovering it explains that no one can call the bot because it is not shared with the right teams. Reps see the same suspended state. Completed work is kept. The task resumes once the bot is visible to all of the module's teams again, either when you restore access or when someone else does.

FAQs

Need help?

Reach out via the chat button or email support@hyperbound.ai.