Branching is a powerful mechanism that poses limits on what a user can access. However, sometimes it might be difficult to understand what a user can actually see, and why. So let's clarify how this works:

Branches in eFront have a tree-like structure. You can create a branch either at the “root” level (without a parent) or specify another branch as its parent (making it a “sub-branch”).

This way it is possible to create a tree of branches, that resembles an organizational chart. Each tree is totally separated from its siblings so that users in one tree have no knowledge whatsoever of the existence of other trees, nor its members, data, etc. In fact, you can create branches with their own, unique URL.

An example will help: Suppose our platform hosts training for 2 different organizations, called “Acme” and “FooBar”. Let's assume that Acme has departments called “Marketing”, “Management”, “Sales” and FooBar has “Partners”, “Affiliates” and “Stores”, with the latter having 2 additional sub-branches. Their structure would be like this:

          Acme                            FooBar
         /  |  \                         /  |  \
Marketing Sales Management       Partners Stores Affiliates
                                           / \
                                       Owned Franchise         

In the above structure, any user assigned to the “Acme” branch, or any branch below it, has no knowledge of the existence of FooBar, or any of its users, courses, progress etc. If our eFront platform lies in “efront.example.com”, then the first branch might be accessible from “acme.efront.example.com” and the “Foobar” could be from “training.foobar.com”.

Note: “Acme” and “Foobar” were chosen as fictitious companies, we are not related or endorse in any way with actual websites or companies with these names.

There are 2 ways for a user to become a member of a branch:

• The system administrator assigns the user to a branch
• The user visits a branch's URL and self-signs up

For example, a user who visits http://efront.example.com and signs up, will not be associated with any branch. But if a user visits training.foobar.com then they will be placed automatically in this branch.

If a user that is assigned to a branch has an “administrator” type, then he will be considered to be a “branch administrator”. This means that the user has full access to their branch and sub branches, but does not have access to other branches or global settings.

If a user is not associated with any branch, they are considered to be part of the “global” context.

•  Groups, Skills, Jobs, etc

A branch administrator can create any kind of entity under his/her branch: Jobs, Groups, Skills etc. Anything that is created in a branch is “attached” to the root of the branch tree, and is thus available to all the members of the branch tree.

In our previous example, if the branch administrator of Acme's “Sales” branch creates a new Job called “Sales representative”, then this job will be made available across the whole “Acme” tree (the Acme branch and its sub-branches).

It will also be visible to all users that are part of the “Global” context (not associated with any branch). However, it will be invisible to users that are part of the “FooBar” branch tree.

Entities that are created in the global context are by default visible to all branches. For example, if the System Administrator creates a new Skill called “Project management”, it will be visible to every user throughout the system.

Things are a little different when it comes to the training itself. In order for a course to be available to a branch, it has to be explicitly assigned to it, and it is not inherited by its parent branches.

This allows for fine-tuning of what training is available to every level. For example, let's suppose that the system administrator creates the course “Training for Project Managers”.

In order for it to be available to the “Acme” branch, the system, they have to assign the course to it. If they need to make it available to Acme's sub-branches too, then again they must assign it to each one separately (or simply select “assign to sub-branches).

Courses that are assigned to a branch cannot be changed by the branch administrator. They can only be edited by Trainers, provided that their user type's permissions are such that this is allowed.

In addition, when a course is made available to a branch, then its lessons are also available to it so that a branch admin can create a new course with some or all of the lessons that were included in the original course. However, these, too, cannot be modified or deleted by the branch administrator.

The fact that users from unrelated branches can be enrolled in the same course, has side-effects that, depending on the use case, can be considered as positive or negative.

For example, by default, a course is associated with a discussion. Users from different branches can participate in the same discussion, without interfering with each other (or in any way acknowledging each other's presence). However, a user of the “Global Context” will be able to see all users' posts and reply to them.

Similarly, when viewing reports for a course, the system administrator gets an overview of all the users of the system, where the branch administrator sees only the progress of the users in his own branch.