I don’t know about pointers but can give you our methodology. We used branches to mimic the hierarchy of the company so that users within branches had views over this in the same branch (instructors to students) and then we leverage groups to create other more unofficial grouping types which may be sub sets within the structure or occur across parts of the structure. 

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.  

Think it also helps to think about what you can do with branches and groups. While it is a good idea to mimic your internal department hierarchy in with branches and sub-branches, it may not always the final solution. 

When creating branches you can also think about things like:

• What will our admins (power users) need to access and do and will we need to restrict them to specific group or branch
• if you are using multi-domains, you will need at least 1 branch for each sub domain
• Branches can make the control over pages and menus much easier and you can also use a cross-section or combination of Branches and Groups to carve out niche areas if needed. The latter is one is one we use quite a bit as we display different meus and pages some times when we are piloting new initiatives, etc.
• another lesser known benefit of branches is...if you are using “additional fields”, each branch ca bet set to see only those custom fields you desire...very helpful if you have your PU’s doing profile maintenance/updates
• Branches are very easy to move around or amalgamate when needed
• Branches can also help to keep your data and other branches clean...for example, we created a branch for “deactivated users” so we can have them apart from ‘live’ branches re: reporting, enrollments, etc. but maintain them for archival and historical reporting purposes

Hope you can find some useful tips...there are probably more but I can thin of them right now...

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

for the most part, groups are more flexible if you have additional fields setup and want to create groups based on completions. branches are really only need if you are setting up multi domain/SSO.

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. 

@steveninfinger : You mentioned that each department under the internal structure would have a sub org.  Is that the deepest that your structure goes then?  Internal →  Dept  → Sub-dept.  Also, do you anticipate any performance issues related to using branches this way?  

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

@steveninfinger Thanks for the clarification.  We are looking to go maybe 8 or 9 levels deep (if applicable) after the root branch > Internal.  There is concern about doing so since the Docebo help pages don’t make it sound like a good decision (movement/org changes/org relationships).  Being able to create enrollment rules, groups, and reports that go to those levels is what is driving the investigation. 

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

@steveninfinger each person will be in a single branch.  We would use our org structure for each branch so a single person could be pretty deep on the structure.  We are concerned that using a deep branch structure will cause performance issues and that management of the branches would be hard as people move from time to time.  Are individuals moving often?  No. But movement happens. We have over 150,000 employees and reorgs or job changes happen. 

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

@Annarose.Peterson for your external users, what is your nonsubscriber content? Right now, we’re only B2B, but eventually will be B2C and that seems like a really smart set up for us down the road. 

@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?

The same content is available for both our Subscribers and non-subscribers.  Our courses must be purchased, and our subscribers are provided with subscription licenses so that our courses are labeled as “purchased” for them, and they can freely enroll into those courses.  

Non-subscribers will see the same courses, but with pricing, so they must go through a payment gateway before they can enroll. 

We ultimately decided to put our subscribers and non-subscribers into separate parent branches, so that we can have more control over which pages/menus the non-subscribers see.  Let us provide more marketing to those non-subscribers, versus those who have already purchased subscriptions.

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

This discussion has been helpful. We’re also in implementation and trying to figure out our structure. I like the idea of keeping things simple. I’m thinking one branch for Board Members (who are required to take some training) and one branch for Employees. 

I’m wondering about reporting, though. Does the branch structure have any implications for reporting that I should understand? Would it be “too” simple to have all employees in one branch when it comes to reporting?

Thanks for any insight you may have!

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?

The way I view branches is think big hierarchy, groups are used for smaller subset of users for example new supervisors, new hires, etc..) I hope that helps.