Best Practices for Setting up Branches and Groups

We’re also going through implementation. We’re consolidating multiple department level LMSs we have in our company using Docebo as a single LMS that will handle internal training for multiple teams and our external training for paying customers. At the highest level we have our Company then an Internal Branch and an External Branch

Internal: each department will get their own sub branch

External: Since we sell our training around the world and across multiple currencies we have to have a domain for each currency. Therefore the next level is for each country and then another level with each customer organization getting their branch.  

Couple of other things about Branches that may also be helpful to keep in mind:

User can belong to multiple groups, but only one branch (or sub-branch).

So with that (generally), Branches would be an organizational strategy for things that don’t change very often about that user (internal/external, department/business unit, etc.)

At the time we implemented the system documentation advised against having niche branches and groups as it can become cumbersome and tedious to manage. This became immediately apparent when you consider that visibility into everything (e.g., pages, menus, catalogs, channels) in the system is managed through branches/groups. We’re a small team and didn’t want to take on the level of administration (i.e., managing and maintaining multiple groups and competing visibility settings for each catalog and channel).

• We have two branches: Internal Employees and External Partners
• We have two language groups for each branch: English and French

We target BUs through channels and catalogs. I work in insurance so our catalogs are split into things like Auto Lines, Property Lines, Claims Lines, etc. We also have high-level catalogs for general learning. Things like technical skills (e.g., MS Office) and soft skills (e.g., problem solving).

The bottom line is that ALL employees can see ALL content. We’re not in the business of locking down training and hiding it from certain groups. Most folks access the system through direct links to catalogs or courses and our navigation is intuitive for those that come in through the home page. 

For reporting, you can still get BU level data if you have a BU additional field. Since our HR BU data isn’t the cleanest of data, we opted to manage this outside the system through excel and vlookups. 

I’m grateful for taking this approach. Our system is relatively easy to manage and troubleshooting is usually a breeze. I kept reiterating the same thing during implementation, “the more moving parts we add, the more likely it is to break, the harder it is to fix.” Keep it simple. 

@gkarofa1 so it’ll actually be root branch > internal > department. I suppose that’s what you said, but just want to clarify we’re doing down 3 levels not 4. There was concerns since Docebo doesn’t recommend a wild branch structure, but we’ve talked it out multiple times with our SDM and he says it should work. 

@gkarofa1 will people be in multiple branches or single branches, but possibly in a deep sub branch level?

I mentioned this in another post about branches, but when we implemented, we sat down for a long time and considered all our possible user experiences to determine what our structure would be.

We are using the extended enterprise, so each main multi-domain has its own parent branch (in our case it is internal/external users).

Internal users: we have a branch for each department. An obstacle we encountered was managers may have direct reports in different departments, so we have a group for each manager.  The group assignment is automatic based on a free text additional field where the manager’s name is populated. Managers have power user access to their specific group, so they don’t have to see folks that are not their direct reports.

External users: They are a separated between our subscriber users and guest users, then each client (or external organization) has its own sub-branch under the appropriate subscriber/guest user branch.  This way when a guest turns into a subscriber, it is easy enough to move that sub-branch.

Adding a second level to our branch structure for our external users allows us to have special pages for our guest users where they can receive different messaging (like marketing to drive them to become subscribers). 

@steveninfinger  and @Annarose.Peterson 

• Does your organization have a lot of movement from one branch to another and is that movement automated or manual?  I believe you both may have said manual but just in case...
  • If automated, can you give any insights to how it’s done?
  • Have you seen any limitations on how many users can be moved from one branch to another at one time? (maybe see issues with over 20k etc.)
• Are you assigning training using the branch(s) and/or groups?
• Did you have trouble implementing your branch structures?

@gkarofa1 the actual adding and deleting and moving of branches we do manually since they don’t change often.  We have users change departments, so we manage that with the Automation App where we have a user CSV import happen automatically every day that moves users to new branches.

We do not move nearly as many folks as you have mentioned!  User import usually handles maybe a few branch updates every day, so I don’t know what kind of performance issues you might run into if you have a background job that big to move that many users into new branches.

We assign training to both branches and groups, it depends on the audience the courses are being assigned to (our internal users are in branches based on their department, but they are placed into groups based on who their manager is), but we have been able to assign training to about 600 users within a parent branch with no problem.

When we implemented, the only thing that was giving us trouble was making sure the user import that happened every day was moving users correctly, so we did a lot of testing in our sandbox, but once we had it working it has been nice to not have to worry about updating user profiles.

We had this scenario when we implemented last year.  In the end we went with Branches for our offices, so we could assign location specific training to the branches, and then used groups for everything else. 

We found this the easiest way as we needed our Lawyers to be part of multiple groups (for example a Senior Associate would be in the Lawyer group, the Senior Associate group, the practise area group and the specialism group as a minimum.

We found aligning catalogues with groups made it so much easier to assign training to the specific people to make it as personalised as possible.

Hope this helps?