Branching is a powerful mechanism that poses limits in 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 eFrontPro 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 “subbranch”). This way it is possible to create a tree of branches, that resembles to an organisational chart. Each tree is totally separated by 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 organisations, 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 subbranches. 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 eFrontPro 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 sings up, will not be associated to any branch. But if a user visits training.foobar.com he/she 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 over his/her branch and subbranches, but does not have access to other branches or global settings.
If a user is not associated to any branch, he/she is considered to be part of the “global” context.
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 node 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 subbranches). It will also be visible to all users that are part of the “Global” context (not associated to 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 training itself. In order for a course to be made 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, he/she has to assign it to it. If he/she needs to make it available to Acme's subbranches too, then he/she must assign it to each one separately (or simply select “assign to subbranches).
Courses that are assigned to a branch can not 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 to 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 to a discussion. Users from different branches can participate on 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 across the system, where the branch administrator sees only the progress of the users in his own branch.