Knowledge base Rise Up

Group Hierarchy: The Essential Guide for the Group Manager

  • Updated
Prerequisites
• Administrator access to the Rise Up platform or Group Manager rights.
• Your organizational structure must be clarified (groups, subgroups, managers, use cases).

Tip: prepare your mapping before implementation

Why? Good mapping avoids: incorrect notifications, wrong group membership, duplicated groups, costly re-parenting.

How to do it easily:
  • Sketch it in 3 columns: Groups → Managers → Direct members.
  • Mark a ✓ for groups visible in the catalog; a 🔒 for internal (non-visible) groups.
  • Decide “who is direct where”: this determines rights, visibility, and notifications.
  • Keep a reasonable depth (recommended maximum: 7 levels) for clarity and performance.
  • List in advance the Smart Rules that will auto-enroll members.

The 3 pillars to remember

  1. Direct vs Indirect: Direct defines responsibility and notifications; Indirect propagates upward to parent groups.
  2. Parent → Children: a parent group’s manager can view and act (depending on permissions) on the entire subtree.
  3. Permissions: the selected options (e.g., All courses) directly expand the manager’s scope of action.

Understanding group hierarchy

A group = a container of users, subgroups, and rights. Each group has 0 or 1 parent and can have multiple children.

Direct member: the user is added inside the group.
Indirect member: the user appears automatically in parent groups through propagation.

Practical consequences:

  • Notifications are sent only to the manager of the user’s direct membership group.
  • Reports and dashboards at parent level aggregate the activity of all subgroups.
  • Management actions (enroll, unenroll, view progress…) depend on the role + configured permissions.

 

Simple diagram — Hierarchy & visibility (real example)

Aerodynamics Internal Logics  [Manager: James]  (51 users)
├─ Computational Fluid Dynamics                [Manager: Aïko]      (10)
└─ Design & Simulation                         [Manager: Jasmine]   (40)
   ├─ Design & Simulation — Beijing, China     [Manager: Isabella]  (10)  ← Alexander (Direct)
   ├─ Design & Simulation — Delft, Netherlands [Manager: Henry]     (20)
   └─ Design & Simulation — Melbourne, AUS     [Manager: Daniel]    (10)

Legend:
• [Manager: …] = Group manager
• Alexander (Direct) = direct member of subgroup “Beijing”
• Propagation: Alexander is indirect in “Design & Simulation” then “Aerodynamics Internal Logics”
• A parent’s Manager (James) sees his group + all subgroups and their members

Administrator: scope & permissions

  • Full visibility: entire hierarchy, all groups and members.
  • Groups: create/edit/delete anywhere; unrestricted re-parenting.
  • Users: create/edit/delete any profile; manage statuses and enrollments.
  • Roles: assign/remove Manager rights (parent or child groups).
  • Smart Rules: configure or audit automated rules.

Accessing group editing

Structuring the hierarchy

Important — Permissions & actual scope
1) In Group configuration, the choices “All courses / Visible courses only / Authorized list” precisely define what the Manager can manage (enroll, unenroll, view).
2) Manager at parent = inherited scope: if James is Manager of Aerodynamics Internal Logics and the permission is “All courses”, then James can fully manage all subgroups (Design & Simulation, CFD, Beijing, Delft, Melbourne…).
3) To limit scope: place the manager at the desired subgroup, or restrict the list of authorized courses/paths at the parent level.
CleanShot 2025-10-22 at 11.32.41@2x.png

Group Manager: role & scope

Visibility

  • Sees users, their activity (time spent, progress, score) and groupings for their group + all subgroups.
  • Does not see upper levels or “sibling” branches (unless explicitly granted).

Action rights (if authorized)

  • Create subgroups; edit the name, visibility, image, and Smart Rules within their scope.
  • Create/edit users in the group; the membership is automatically propagated upward to parents.
  • Enroll/unenroll in courses and paths included in the allowed scope.
  • Notifications: only for the direct members of the managed group.

Configuring Group Manager rights

Default scope: the group where the role is assigned + all its subgroups

Groups
├─ Allow creation/modification of groups
└─ Allow management of managed groups

Users
├─ Allow creation/modification of users in the group
├─ Allow modification (without creation)
└─ Allow confirmation of their own course enrollments

Notes:
• Optional cumulative permissions
• Re-parenting = sensitive action with restrictions
• Notifications = Direct members only
See the step-by-step tutorial in the embedded video above.

 

Details of Manager options — “what it really changes”

  • Create & edit groups: allows the branch to grow (e.g. Isabella creates “Beijing — Onboarding”).
  • Manage their groups: access to monitoring screens (members, stats, export), smart rules, filters.
  • Create & edit users: useful for local onboarding (e.g., creating trainee accounts in Beijing).
  • Confirm their own enrollments: autonomy over their own learning without admin support.

Add & manage members (step-by-step)

  1. Membership & propagation — Adding Benjamin to Design & Simulation — Beijing ⇒ Direct in “Beijing”, Indirect in “Design & Simulation” then “Aerodynamics Internal Logics”. 
    Aerodynamics Internal Logics  [Manager: James]
└─ Design & Simulation         [Manager: Jasmine]
   └─ Design & Simulation — Beijing  [Manager: Isabella]  ← Benjamin (Direct)
    Good practice: Always verify where the direct membership is: it controls who receives notifications.
  2. Notifications — Isabella (manager of “Beijing”) receives emails for Benjamin. James (parent) receives nothing by default, even if he sees Benjamin in dashboards.

Create & reorganize groups

  • Create subgroups: only under their group (unless specific permissions).
  • Re-parenting: sensitive action that triggers a recalculation of indirect memberships and may shift responsibility (and notifications).
  • Deletion: children become orphans; verify Smart Rules and connections afterwards.
Concrete example — If “Design & Simulation — Beijing” is moved under “Computational Fluid Dynamics”:
  • “Beijing” members become indirect members of “CFD” then “Aerodynamics Internal Logics”.
  • They are no longer visible from “Design & Simulation”.
  • Notifications change if direct membership was modified.

Use cases (aligned with diagrams)

  • Indirect membership — Alexander is Direct in Design & Simulation — Beijing and Indirect in Design & Simulation Aerodynamics Internal Logics.
  • Manager scope — James (parent manager) sees and administrates the whole branch (according to permissions); Isabella (subgroup manager) only manages “Beijing”.
  • Local user creation — A subgroup manager creates an account: the user is automatically propagated upward (indirect).
  • Controlled re-parenting — Moving “Beijing” under “CFD” changes aggregated visibility and can change which manager receives notifications.
  • Targeted notifications — Only the manager of the direct group receives emails (e.g., Isabella for Alexander/Benjamin).

Comparison: Administrator vs Group Manager

Feature Administrator Group Manager
Visibility scope Entire structure Their group + subgroups
Group creation Anywhere Under their group (if authorized)
Re-parenting Yes (controlled) Within their scope (if authorized)
User creation/editing Yes Members of their group (if authorized)
Email notifications According to global configuration Direct members only

FAQ & Troubleshooting

  • Issue: I cannot see users from another department.
    Solution: Visibility follows the hierarchy. Assign the role at the correct level or request explicit permission.

    Issue: Cannot attach a subgroup to a parent outside my scope.
    Solution: Re-parenting is restricted. Request admin intervention or a temporary extended right.

    Issue: After re-parenting, some members “disappear” from the former parent.
    Solution: Normal: indirect memberships are recalculated; use the change log to track the operation.

    Issue: I receive too many emails.
    Solution: Only direct members trigger notifications; verify where the direct membership is and who the manager is.

    Issue: My Smart Rules no longer behave as before.
    Solution: Revalidate the rules after a hierarchy update (parent/child) or group visibility change.
  • Can a Manager see higher-level groups?
    − No, unless explicitly authorized.
    Can they attach a group to a parent outside their scope?
    − No, unless granted specific rights.
    Recommended maximum depth?
    − 7 levels.
    Does duplicate cleanup modify manager roles?
    − No.
    Do managers receive notifications for indirect members?
    − No, only direct ones.

    New:
    Limit display to main parent? − Yes, a dedicated option exists.
    Show number of Smart Rules in group list? − Yes, useful to quickly spot automated branches.
    Search/filter on Groups page − Lists relevant groups and shows the parent next to each; a filter isolates groups without hierarchy.
  • For further assistance, submit a request:
    [Rise Up Support Request]

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request