One LMS, many teams, each with its own admin
Branches for your locations, organizations for client companies, groups for cohorts, and a role ladder that stops anyone from granting more access than they hold.
At a glance
- Branches
- Client organizations
- Groups and cohorts
- Seven-rung role ladder
- Menu permissions
Most LMS installs start with one admin and one audience. Then a second site opens, a client asks for its own login page, and a department head wants to add their own people without filing a ticket. If the platform only knows “admin” and “learner”, you end up handing out admin rights you would rather keep.
LMS Advisor gives you four ways to divide the platform: branches for your own locations, organizations for client companies or departments, groups for cohorts, and a role ladder with seven rungs. Each one answers a different question. Branches decide who sees whose data. Organizations carry seats, branding and a self-service manager portal. Roles decide who can do what, and nobody can hand out a role at or above their own.
What breaks when one admin runs everything
Admin rights handed out as a shortcut
A site lead needs to add three new starters, so they get full admin. Six months later a dozen people can change SSO settings.
Clients who expect their own space
A corporate customer wants its logo on the login page, a seat count it can see, and a manager who can pull a completion report without emailing you.
Locations that should not see each other
The Phoenix clinic manager has no reason to browse learner records from the Denver clinic, but still needs to run their own team.
The building blocks you get
Pick the structure that matches the question you are answering. You can use all four at once, and each has its own screen in the admin menu.
Branches
Give each site or division a name, code, logo and branch manager. Switch on branch isolation and staff below admin see only their own branch.
Client organizations
Seat limits, a branded login page, courses with due dates, and a portal for the client’s own managers.
Groups and cohorts
Put learners in a group, assign a course once, and every current member is enrolled. Each group has its own progress report.
Seven-rung role ladder
Student, instructor, course manager, branch manager, manager, admin and super admin. You can only grant roles below your own.
Menu permissions
Super admins choose which roles see each admin menu item, and the same rule is enforced on the page address, not only in the menu.
Audited impersonation
Admins can sign in as a user to reproduce a problem. Sessions cannot be nested, and each start and return is written to the audit log.
How the structure fits together
Branches decide who sees whose data
A branch has a name, a short code, an optional parent organization, a logo and an active flag. Users and courses each belong to a branch. The part that matters is the branch isolation setting, which ships switched off. Turn it on and every role below admin (branch manager, manager, course manager, instructor and student) sees only users and courses in its own branch. Super admins and admins keep the full view.
Do one thing before you flip it: give everyone a branch. A scoped user with no branch sees nothing at all, which is the safe way to fail but will fill your inbox. Deleting a branch unassigns its users and courses. It does not delete them.
Organizations are client accounts with their own portal
Each organization has a seat limit (every member counts, managers included), its own logo, colors, font and optional custom CSS, and a login slug with its own heading, text and background image. When you assign a course to an organization you set a due date and whether it is mandatory, and every current member is enrolled at once. Removing it later revokes those enrollments, so take care.
Members are either employees or managers. Managers get a separate portal limited to their organization, and you decide per manager whether they can assign courses, remove courses, manage members or create accounts. They add learners by pasting one line per person (email, name, department), and the import stops when seats run out. Their reports export as CSV, Excel or PDF, and what they do lands in the organization’s activity log.
The role ladder
Roles rank in a fixed order: student, instructor, course manager, then branch manager and manager at the same level, then admin and super admin. The rule is applied everywhere: you cannot edit an account at or above your rank, and you cannot grant a role at or above your own. That holds on the Users screen, in the bulk importer, through the API, and for SAML and SCIM group mappings, which are capped at admin. A refused attempt is recorded in the audit log as a privilege denial.
You can have several super admins, and they can manage each other, but the last active super admin cannot be demoted, deactivated or deleted. That spares a self-hosted install the classic lockout where the only fix is a database query.
Tenants, honestly
There is also a Tenants screen for separate branded environments on their own subdomain, with user data scoped by account. It is early, so if tenants are central to your plans, ask us first what is covered today. We do not run a white-label reseller program.
See Enterprise Management in a live demo
We will show it with your own scenario, answer the security questions and send a written quote after the call.
Setting up a multi-team install
Map the structure
Decide what is a branch (your sites), an organization (a client or department with seats) and a group (a cohort). Most installs need two of the three.
Create accounts in bulk
Import a JSON file of up to 5,000 users per run from the Users screen, or connect SCIM so your directory creates and deactivates accounts for you.
Hand out roles, lowest first
Give each person the smallest role that does the job, then use Menu Permissions to hide screens a role never needs.
Assign training
Assign courses to groups or organizations. For organizations, add a due date and mark the course mandatory where it is.
Switch on isolation and check it
Once every user has a branch, turn on branch isolation and check a branch manager’s view by impersonating one.
Who sets it up this way
Clinics, plants or stores under one brand
Each site is a branch with its own manager. Site leads see their own records, while head office reports across all of them.
Training providers with corporate clients
Each client is an organization with a seat count, a branded login page and a manager who pulls their own completion report.
Content teams kept out of settings
Course managers build and maintain courses without access to SSO, integrations or system settings.
Groups with several subsidiaries
Each subsidiary becomes an organization, and a shared compliance course goes to each with its own due date.
What your admins get back
- Site managers run their own teams without holding admin rights
- Clients get a branded space and self-service reporting
- No role can quietly promote itself or anyone else
- Bulk onboarding with a record of who created each account
- Head office still sees across every branch and client