Our implementation contact recommended that we keep our branches simple then use groups for fine tuning access. Thats worked out well for us. Our branch structure is based on our regions so we basically have North America, Latin America, Asia and Europe/Middle East/Africa. All users data are imported by region and assigned to their respective branch. The data feed includes worker type, business unit, country, state, city, department and the IsAManager field. From that I can create automated groups for all my needs. 

We use automated groups for each country, city and department for reporting and for practice specific channels or course catalogs. The IsAManager group lets me make our management and legal training available just to managers. This is helpful because whenever someone is promoted, they’re added to the right group on the next data update. I can also combine fields to create groups for special situations. For example, we had some legal training we needed to do for managers in just one state so I built a group with IsAManager + State = XX, then added the training to a channel just for that group. Has worked out well so far.

Our organisation uses a federated model - where we oversee everything but allow our Member Organisations (MOs) to manage their own ‘stuff’ if they want. This helps us share course content to all of our MOs as we provide a default experience for our MOs, but they can also do something unique (we refer to that as local needs). We do provide courses on what we do (our standards and services) to all MOs and they can provide their own courses as well. 

We also require MOs to provide at least one person to learn the system (if they have local needs) and after completing training at Docebo University and then passing some tests in our system, they become Power Users. Having all of their users in their branch makes assigning those resources easier.

We use groups to fine tune access as well (like @rich.schmick mentioned). People Managers are in a group (and yes, this is manual at this time), which allows us to give them access to specific content/courses. We also use groups for our support team to provide them access to customised content/courses.

Hope that helps. 

The last two organizations I worked with, the branches are organized by Audience groups (internal, external, contractors, etc).  This was especially helpful when it came to the Extended Enterprise (since you assign each separate domain to a branch).  Then if necessary, some branches had further sub-branches to help organize users better.

For example, for internal users (or employees), they would be organized into the main “Employee” branch, but each department had their own sub-branch under the “Employee” branch, so that we could easily report on each department.

Then we use groups to create a collection of users that intersect the different sub-branches.  For example, a manager who has power user permissions to help manage their team, and that team consists of employees from different departments.  Rather than give the manager power user access to all the users within a sub-branch, we are able to create a group of just their direct reports for them to manage.

We organise branches based on geo location and country, e.g.

• UK&I
  • UK
  • Ireland
• APAC
• EUROPE, etc.
  • Italy
  • Netherlands

I use branches rarely, so what matters is Department, Sub-department and Team, that’s how I mostly set my groups up (of course along with Location / Employee Level and Worker Type).