Branches and Groups are the two main ways to organize/combine similar users in the platform into a collection of users.
The collection of users can then be:
- Assigned particular Course(s) or Learning Plan(s)
- Assigned visibility to particular Menu/Page(s), Catalog(s), or Channel(s)
- Presented certain additional fields during self-registration
- Used for filters in Reports
While there are many criteria to consider when creating branches and/or groups, this document should serve as a reference to help establish the best use of branches or groups and define which method for user organization is most applicable 
.
Below you will find some initial branch and group consideration questions. To see the answers, click ‘show content’.
Initial Branch Considerations
Are you using a Multi-domain/Extended Enterprise?
- As each extended enterprise is defined only by branch(not groups), and can only be assigned to 1 Branch/sub-branchesy, it is recommended that you ask additional questions around what collection of users the extended enterprise will accommodate. This question should help define your branch considerations. The 3 main reasons for Extended Enterprise are:
-
presenting a different branding look a feel to an audience of users (logo and Login page)
-
allowing for the separate setup of a different IDP/ Single sign on experience for an audience of users
-
allowing for the setup of a different currency/payment gateway settings for an audience of users
Note: the setup for extended enterprise can only be configured either for 1 particular sub-branch or to include a parent branch and all of its “children” sub-branches.
How often will a group or branch change for a user?
- The more nested the branching structure and frequent the change in branches for a single user, the harder it may become to maintain users within branches. It is recommended that a client with a use case where users who would change branches often maybe better accommodated by using a combination of additional fields/groups instead. If branches are absolutely required, it is recommended that branch code be utilized in combination with an import of a user csv file to facilitate the moving of users to his/her updated branch.
Would the user belong to more than 1 branch?
- Any newly created platforms (after 10/16/2019) only allow for a user to be assigned to 1 branch at a time. If the User needs to belong to more than 1 branch it is suggested that you create additional fields and groups to accommodate the segmenting of users instead of branches.
Note: there is an option that the Product team can enable in order for a user to belong to more than 1 branch, but it is only suggested you utilize this option if additional fields and groups will not accommodate the use case. There should also be a mention to the client that a user existing in more than 1 branch could cause the user to receive more than 1 notification which are configured for branches.
Do you have an organizational structure to replicate?
- Often times using an organizational structure can be a perfect model for creating branches and sub-branches since content visibility is often assigned based on where a user lives within an organization. It is important to consider the amount of “nesting” (sub-branches) that will be created based on the organization structure as it could be difficult to maintain more than 3-4 levels deep. Also, be aware that if you have purchased the Salesforce integration and are syncing SF users and/or SF contacts, the integration only allows for:
-
a setup of 3 levels for SF contacts (Parent/sub-branch 1/sub-branch 2)
-
a setup of 2 levels for SF users (Parent/sub-branch 1)
What are the training audiences that need to be addressed?
- In addition to setup by Organization structure, you might consider a branching structure that accommodates segmenting users based on needs to enrol into courses or learning plans, filtering for reporting, and visibility to pages/channels/catalogs. Some other ideas for branch structure are as follows:
Organizational Structure (ex: Internal, External, Clients, Partners)
Product or Deployment Types (ex: Foundation, Enterprise, Reseller)
-
Region/Location (ex: North, South, State)
-
Departments (ex: Sales, Human Resources, Marketing)
-
Business Units
-
Role of Users (ex: Executive, Manager, Supervisor)
-
Regions/Countries
-
Regional Managers/Franchises
-
Client Names
-
Product Names
-
Service Tiers (ex: Gold, Silver, 1st, 2nd)
Are you utilizing Power Users that need to manage a group of users?
- If you have a use case for Power Users, keep in mind that a Power User needs to be assigned users to manage. There is an option when importing users via CSV that allows for the automatic mapping of all users within a branch to be assigned to a Power User while importing. This feature can help by cutting down on the amount of manual assigning of users done on the Power User Management screen. In this use case, typically you would create branches based on collections of users who the Power User needs to manage. Please reference the KB for criteria for import.
If Importing user using a CSV, what capabilities does the HRIS/CRM have for exporting user attribute fields, especially branch code/branch name?
- There is a maximum of 50 additional fields per platform so it’s important know ‘what fields of information are relevant when reporting on a user’. Make sure to check for consistency of information coming from HRIS/CRM as inconsistent fields of information could lead to faulty/incorrect reporting (think “garbage in/garbage out”). Especially consider how a user will be assigned to a branch (ex: is a branch code/ branch name exportable from HRIS/CRM?), as this field of information is absolutely critical to ensure a user is assigned to the correct branch. Also, if you have a FTP/SFTP, you might be able to utilize the Automation App to import a user CSV file on a timed basis.
If using Single Sign On (User provisioning), is there a field in the Identity Provider (IDP) which can be used to assign users to the correct branch?
- As users who don’t have a branch code/ branch name defined are assigned to the root/parent branch (not best practice), you want to make sure your IDP has a way to identify what branch a user belongs to. Make sure you knows/configure the correct attribute statement mapping in SAML or Open ID’s user provisioning section in the Docebo platform. If your IDP does not have a field for branch code/branch path:
- you could utilize additional field/groups as alternative way to segmenting users
-
you could import a CSV update file which contains User Name and branch code/branch name to update the user after they have been provisioned by Single Sign on
Branches - Other Tips and Recommendations
-
Automate Branch Creation: if a user has many branch and sub-branches to create there are 2 ways in which they can import branches names/code into the platform instead of manually creating each branch on the user management screen
-
Import Branch Code Path/Branch Name Path-
-
Note: this method require a username in the CSV import for each branch in order to avoid the: “username doesn’t exist error message”
-
-
Self-Registration Options: When dealing with a use case where your client is utilizing Self Registration, there are a couple of settings to consider.
-
Registration/Branch Codes- this setting will allow for user to select the correct branch to be assigned to once registration is completed.
-
Additional field Visibility by Branch- enabling this option will allow you to assign additional fields for each branch individually.
-
Initial Group Considerations:
What type of automatic conditions (additional fields) need to exist to build group/training audience?
-
As you have the use of 50 additional fields, users’ attributes can also be utilized in order to automatically build groups. Since Users can belong to 1 or more groups, this gives you a more dynamic approach to establishing collections of users that might need to be grouped in order to provide certain visibility (pages, catalogs, channels) or help with filtered reporting needs. Additional fields can be populated by import of CSV or be presented to each user as mandatory field you request he/she populates as they log into the platform. Tasks for User management setup are as follows:
-
decide which additional fields are needed for each user,
-
how each field is obtained and scrubbed
-
if each additional field might be used to auto populate a group.
-
Does a user have more than 1 role/title/position/specialty?
- There may be the use case where a user has more than 1 role, position, title or specialty. In each case, the user then needs to have content assigned to them based on this role,etc. Since a user can’t belong to more than 1 branch, it would be suggested to first create two additional fields (Primary Role, Secondary Role). When you create the group, you can use a set of rules defining at least one condition must be satisfied. You would then configure both additional fields (Primary Role or Secondary Role) to be included in the set of rules for the group.
Do you need to present content in different languages to users?
- Using the what we know about additional fields, when using Groups for content assignment (course, learning plans, catalogs, or channels) or visibility to pages- use a User fields based condition for an Automatic Group and use the Language field to organize users into groups based on their language preferences
Do you have follow up courses/learning plans to assign automatically after initial courses/learning plans have been completed?
- Groups can utilize enrollment status as a condition for automatically populating the group. With this function, for instance, you could assign a user to a group after they have completed a course or learning plan. In addition, an enrollment rule could be setup to automatically assign a user to another course(s)/ learning plan(s) as the group is populated using enrollment rules.
Groups - Other Tips and Recommendations
-
Group Creation: while groups can be populated automatically using conditions from additional fields, the group name does need to manually be created in the platform before it can be populated.
-
Self-Registration/Additional Fields: Be aware that when users are self-registering and filling out additional fields, it recommended to utilize “drop-down” field type as this will lead to less errors on input and also streamline the conditions that need to be created when additional field is used to auto populate a group. Also, if the use case for populating the group depends on an additional field, it is recommend that the additional be marked with a mandatory option, making sure the field is populated with “information”
-
Note: When importing the additional field (dropdown type) check that “field” matches one of the dropdown elements exactly before importing the field for a user.
-
-
Group Reporting: there is not a great way to report all of the groups that have been setup in a platform but if you need a list we recommend using the following API Call in order get a list of all groups; https://{Yourplatform}/manage/v1/group
Automation App: as most will assign attributes to each power user utilizing the Power User management screen, be aware that you can assign attributes to the power user by importing a CSV file via the automation app. The KB article will provide a list to help assist the needed columns and mapping for the import. This feature might come in handy if you need to setup more than 20 power users.
Branch and Groups Visuals
