Opinions Wanted: When does it *NOT* make sense to leverage groups?

One point I think adds to those considerations is reporting. Are you ever going to need to categorize this user by your group/will they need to be a place where you can pull their enrollments based on their group membership?

I think part of the problem too is that, although Docebo is trying to keep up to date, the support for groups in the system itself is fundamentally different than branches, with some settings being only reliant on groups and other only reliant on branches or other audience groupings. Are there specific situations in which group membership is not supported for user organization, and will that impact the admin’s ability to use that feature?

This is a very interesting question, and I am excited to see what others have to say!

Great point! Reporting was in my blind spot for this org. Thanks, Hailey!

Hi ​@shanejacques - if they are a non-profit with negligible information in a user’s profile, which limits the value of automatic groups, then you are stuck with manual. You have already ruled out branches.

If there is enough detail in the user profile for automatic groups, that is a great direction since inactive users can automatically be removed.

It is easy enough to use a CSV file with username, course code and “student” in columns for each entry. In addition they can enroll people into more than one course at a time.

I inherited a system with groups like that. It is a mess. The other side of the coin is there is no cost to having 700 groups in a system.

You can put up some pages for the power users with html guidance on best practices and information or videos on how to do the CSV solutions for courses and learning plans.

Hi ​@shanejacques,

Great thoughts on considerations for when to use or not use groups! I can’t really come up with reasons “not” to utilize groups, other than the obvious - for example, when you have only one user in each group.

We have used groups extensively to help identify users from various organizations, geographic areas, role types, training requirements, etc. The key is to implement very sound naming conventions (specifically prefixes) to help you manage the growing number of groups (especially when you have hundreds of them). Until Docebo improves the user interface for the management of groups and enables a folder-like structure for organizing groups, naming conventions are your best bet. This is also very helpful in reporting.

Additionally, if you’re not already doing so, you should try to take advantage of User Additional fields as much as possible. If you are uploading users via a CSV file, it’s simple to include the appropriate field values when the user accounts are created. I’ve found dropdown/picklist fields very helpful, as you can add more options to the field list any time. These field values can then be used to create automated groups, which is very helpful when you need to create smaller sub-groups. 

These two recommendations can help improve the creation/management of enrollment rules, notifications, power user profiles, reporting, pages and menu visibility, etc, etc. I’m sure there are other advantages that you’ve already discovered, but if Branches aren’t the answer for your situation, then Groups are definitively a must!

Best wishes!

When I was setting up groups and really all of the organization structure. we established governance that dictated that we would use groups when we needed to provide content and visibility consistently to a selection of our audience. If it was a one off or single instance, we did not create groups. 

The key was consistently.

This is a very good topic! 😊

We are also using groups extensively. Here are the two biggest use cases where we use them:

• Define a specific learning journey for the users with enrolment rules, dashboard, channels, catalogues. In some cases we use multiple groups in one journey, for instance when someone passes a level, he/she will be added to another group, triggering a different enrolment rule.
• Communicate with a specific group, for instance only Power Users with a specific profile that speak Italian (although in this case we combine this with some API magic)

We also use branches, but they have a different role (mapping users to a specific department or client).

My first thought is always to check if we are creating more complexity than needed, especially for smaller organisations with less resources. A good indication is if you can easily explain your system to your stakeholders. However, this is always easier said than done! Please do not think that I do not struggle with this myself! 😉

We’ve introduced a naming convention in order to get more details directly from the name of the group. By using “-” as a separator, we can use another tool (like Excel) to split the text and have a quick overview of each groups in different journey or category.

I Hope this helps! 

Nothing to add to this other than - 

When we first implemented Docebo back in 2019, groups were a relatively new feature. Our CSM and others who were onboarding us urged me to use groups instead of branches, as groups were the future. This community didn’t exist and I wasn’t sold on the advice I was getting. This actually held up our implementation for a month or so, IIRC. To add to the confusion, I went to the Docebo conference that year and spoke with a Doceboan who insisted privately to just use branches. : )

Eventually, we wound up using a combination. We have large user segments like “External”, “Internal”, with some sub-branches. But we also have a large number of groups, which have proven very usefulf or auto-assignment, as we use Additonal Fields in user profiles extensively. 

• We have a group for each internal cost center, which is the defacto “department” for each employee
• While the vast majority of our external users (customers) are not assigned to a group and exist only within the External branch, we have groups for each partner segment

The UI is obviously much nicer for branches - it’s nice to navigate through folders (though the “Include sub-branches” switch doesn’t seem to work consistently). But groups are very useful. 

We use groups and branches, but I’m more and more convinced that there’s value in creating groups FOR branches, instead of using branches themselves. That allows you to set up an enrollment rule using a combination of groups (some of which represent branches) instead of using groups OR branches. 

This is where my mind has been going, too, Dave! I like the simplicity of this as a decision point. 

My other thought is “Are you looking to quickly enroll a selection of the audience in content on a rolling basis? If so, create a group.” What I’m finding is that they create groups to segment the audience, but only do so to execute an enrollment at one point in time (e.g., an onboarding course). There’s nothing wrong with that, but it feels like using a grenade to kill a mosquito. Now there is a group that will never be used again, when enrollment via CSV might have been just as effective.

I think one of the most important things about using groups is setting a naming convention that will help you (and other admins) to be consistent in your naming so that you can find the groups again, for assignments, cleanup, or other efforts. Your ideal naming convention will be unique to your organization and use case.