We’re a very location based organization as well. What are you using the physical address for, group assignments? Can you keep it high level to the city? Or is the store node at the branch level what controls your assignments? 

@Bart_at_Yamaha Motor  Maybe you have the information of the stores stored in another software and you can link these information with an automatic rule/ an integration / API, so that the information about the user is updated on a daily basis?

@Bart_at_Yamaha Motor - my first question would be “Why?” Why do you need this data in Docebo? What are you trying to achieve? Other than reporting, is there another reason you want that info?

Staying integrated is the only smart way to address this.

@Bart_at_Yamaha Motor is pointing out something that may be a great idea in the making - additional fields for a branch.

We are looking for a good solution to this as well.  It’s looking like we’ll be developing a custom application hosted outside the LMS and integrated via API. But it would GREAT if Docebo could just introduce Branch Additional Fields!

Alan

We also could use some branch additional fields. Our branches each represent one of 400+ customers. We would like to be able to include some reportables there as well - like customer number, subscription type, relationship manager to name a few. 

We’re a much smaller organization, but we more-or-less achieve this scenario with User Additional Fields populated from our HRIS system through API (although before we had that integration setup, we were doing things via CSV exports from the HRIS system, and automatic nightly imports using the Docebo Automation function).

Like you describe, our lowest-level Branch is our individual departments. In addition to branch, mostly for reporting purposes, we have a User Additional Field for department too. Again, while it’s technically the same data in two places (branch and user profile), it’s all managed by our API integration (and previously Docebo Automation via CSV).

Heck I just added the idea for yawl - go vote it up….

This is mine as well. What is the end goal of having it here? Is it to act as just a master additional field that auto applies to all users of the branch? Is it just to have the info somewhere? Seems more like a user creation/update process solve more than a branch thing unless you are trying to trickle info down, at which point Id think the solve is any user level additional field becomes available to apply branch globally from the branch. 

Its the trickle @Bfarkas . When we are automating - this is not a big stressor - we are not stressed because I pass that level of detail along in my feed. For some - some are commenting above - automating that level of detail becomes a non-option. The idea seems plausible.

We also use a location/branch based system. We’ve also added additional fields, but have it sync up with our database platform nightly. This set up allows any changes in the platform to be reflected in the branch. 

If you are creating this for permissioning - we’ve created automatic groups using both branch and additional field requirements in order to populate the groups. 

Furthermore - we also create channels per branch via an API. This would allow your ‘stores’ to upload learning assets, updates, and events seen only by that store. 

I also suggested an idea for additional fields on branches about four years ago, but don’t know what happened to it. Our use case is in the external enterprise. Our reseller partners are enabled to sell different product lines based on partner-specific enabling agreements. We use the branch structure to organize the users for each partner.  We control what training a partner user can access based on the enabled products.

Currently we use an additional field on the user record to list all the product lines enabled for that user/partner. This requires looking up the list when we approve a new partner account and manually editing the account to add the list to the additional field. It would be so much easier and reduce mistakes if we could put the list on the partner branch and have the user account inherit the field value from the branch. The inheritance logic is simple: the user inherits the field value contained in the closest branch node with a non-null value in the field.

Totally understand that, but think it is being described differently. The trickle is an inheritance model where all fields are essentially the same, but you can choose to set them globally by branch, versus branch unique additional fields. Just was trying to clarify that for the use case.

Alternatives to automation, I know folks who just use the branch code as essentially a known look up table value for adding this info to their excel reports later, since for accounting/management/etc would all be the same, so anyone with that code would equal those details and then they can centralize that in one document and use system as is to accomplish without adding a ton of fields.

Hey @Bart_at_Yamaha Motor

You have 9 votes already. You (we ) are doing good - it seems like that idea is resonating.

I think you would want to go one step further and talk through how/where the detail can be further used...it may bring clarity.

Hi all, thank you for commenting on my question. 

@captainzelda , thank you for your reply. When tried to reply, I accidently flagged your reply as ‘best answer’ . but anyway we indeed add a lot of contact information to our stores. Just when reporting is run for instance it is easier to also report more in detail on these branches. Already are branch tree has 7 levels. Adding more differitation would further complicate the administrative maintenance at that point.

@mwd and @Bfarkas , good question and I didn't explain it properly. But like above it is mostly for reporting. But also needed for our dashboarding (custom made). Next to contact information we also store sales representative, after sales representative, region, area, product groups carrierd by the store, ect.. This is then used in the filters of the dashboard in a same way why you may use in filtering in excel reports. 

@dklinger , again thank you for converting it into an idea. Much appreciated.

I apologize in advance for this long post. But I found my original email I sent four years ago to our CSR requesting “branch additional fields.” I’ve edited it and provide it here.

• The branch structure in the Docebo User Management is the widely used hierarchical tree structure abstract data type. Placing a user account in a branch node designates membership of the account in that branch. 
   
• The user account's value from being added to a branch is the branch's hierarchy in the branch organization. If the Extended Enterprise app is enabled, adding the user account to a branch in the extended enterprise client gives the user access to that client.
   
• A user account can be a member of more than one branch.
   
• User additional fields are best described as metadata. The values are "kept inside" the user account, independent of the branch structure. If the user account is moved to a different branch, the user additional field values remain the same.
   
• In a hierarchical tree structure, metadata about a node can be inherited from the parent node. An example already exists in Docebo: the visibility of user additional fields in a branch. This “metadata” stays with the branch. If the user account is moved to a branch with different visibility of user additional fields, then user will see the user additional fields visible in the new branch.
   
• User accounts also inherit the branch name and code. As discussed in this thread, some people encode these fields to include additional metadata they want the user accounts in the branch to inherit. However, Docebo cannot act on this information, only report it.
   
• We need branch additional fields to define metadata on the branch. Data about the branch which stays with the branch. These branch additional fields should behave like user additional fields in Groups and Reports.
   
• My use case example is to define the product lines that users in a branch are enabled to sell and, as a result, have permission to access the associated training, where the branch node represents the reseller partner for which the user works. The enabled products are metadata of the organization, not the user. If the user leaves one partner and joins another, the enabled products stay with the partner branch, not the user account.
   
• Since branches are hierarchical, we need to define inheritance rules for branch metadata:
   
• In the base case, if the branch containing the user account is a top-level node, i.e., without a parent, then the user account inherits the value of the branch additional fields set in the branch.
   
• If the branch containing the user account is a child node, then the user account inherits the value of the branch additional field of the most adjacent branch with a value for the branch additional field. For example, if the branch node containing the user account has a value for the branch additional field, then the user account would inherit that value. If the containing branch does not have a value for the additional field, but the parent branch does, then the user account would inherit the value from the parent branch. This is the same behavior followed by user additional field visibility.
   
• Suppose the user account is in more than one branch, but each branch is within the node of a different Extended Enterprise client. Then the user account would inherit the branch additional field values defined in the branch nodes of the client in which the user is signed in. In other words, the value of the branch additional field would change based on the client.
   
• The complex case is where the user account is in two or more branches within the same client. In that case, following the child node rule to define the metadata values of each branch:
  1. If all the branch additional fields have the same value, then the user account inherits that value.
  2. If only one of the branch additional fields has a value, then the user account inherits that value.
  3. If two or more values for the branch additional field differ, then there are two options:
     1. The user account does not inherit any value for that branch additional field. Although this is simple, it is not desirable.
     2. The user account inherits all the values for the branch additional field. This is the logical option but requires adding a multi-select picklist additional field type, which would be very useful to have on its own in the current user additional fields.
         
• These inheritance rules may seem complex. But they are basic graph theory. Implementing such a system is often one of the first problems taught in a computer programming course to introduce recursion.

Makes sense, thanks for the clarification, curious with a custom dashboard, they can’t take the store information as a separate table and use the branch code’s unique value as a cross reference to give you the same outcome? It’s a pretty common setup in those types of things. 

So, long story short, used for inheritance :)

if you haven’t already, might want to take this onto the idea as well for reference. 

I agree that having Additional Fields for Branches and that properties of the branch be passed onto all people in that branch would be a great help for keeping user information correct.

Users should not be in multiple branches and whatever is making it seem necessary should be rethought and instead managed by Groups.

I’ve considered (over simplified solution description follows) the work around of creating a fake user in the branch that holds all the pertinent information accurately and then passing the changes to rest of the users in the branch via API or having a spreadsheet update that runs very night; wondering if anyone else has.

Have done API setups based off of SharePoint list of variables, make a change to the branch column and that night it updates all the users with the change. Works well.

@Bfarkas Thank you the feedback! This is something we are exploring this quarter and next. Wondering if we need Connect or can this be done without?

Depends on how you want to do it. Connect is the within platform way, but your IT group might have other tools that work just as well to do it too, I heavily use the Office 365 ecosystem as that is what is available to me here.