Branching is a powerful mechanism that limits what users can access. However, it can sometimes be difficult to understand what a user can actually see, and why. Here’s how branch visibility and permissions work in eFront.

Branches structure

Branches in eFront have a tree-like structure. You can create a branch either at the root level, without a parent, or under another branch, making it a sub-branch.

This lets you build a hierarchy that resembles an organizational chart. Each branch tree is separated from sibling trees, so users in one tree have no knowledge of the existence of other trees, their members, or their data. You can also create branches with their own unique URL.

For example, suppose your portal hosts training for two different organizations, called Acme and FooBar. Acme has departments called Marketing, Management, and Sales. FooBar has Partners, Affiliates, and Stores, and Stores has two additional sub-branches.

      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, or progress. If your eFront portal is hosted at efront.example.com, one branch might be accessible from acme.efront.example.com, while another could use training.foobar.com.

Branch membership

There are two 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 URL and signs up there.

For example, a user who visits http://efront.example.com and signs up isn’t associated with any branch. But if a user visits training.foobar.com, they are placed automatically in that branch.

If a user assigned to a branch has the administrator user type, they’re considered a branch administrator. Branch administrators have full access to their own branch and its sub-branches, but they don’t have access to unrelated branches or global settings.

If a user isn’t associated with any branch, they belong to the global context.

Branch ownership and visibility

Groups, skills, jobs, learning paths, and other entities

A branch administrator can create branch-level entities such as Jobs, Groups, Skills, and Learning Paths.

Anything created in a branch is attached to that specific branch, not to the root of the branch tree. That means the entity is available within that branch scope and its sub-branches, but not across sibling branch trees.

For example, if the branch administrator of Acme’s Sales branch creates a new Job called Sales representative, that job is available in the Sales branch and any sub-branches under Sales, but not automatically across the whole Acme tree.

Entities created in the global context are visible throughout the portal unless branch-specific restrictions apply.

Courses, lessons, and curricula

Training content works a little differently. For a course to be available to a branch, it must be explicitly assigned to that branch.

For example, if the system administrator creates a course called Training for Project Managers, they must assign it to the Acme branch to make it available there. If they also want it available in Acme’s sub-branches, they must assign it accordingly, or use the relevant assignment option for sub-branches.

Branch administrators can edit courses that are created within their own branch scope. They can’t directly edit global courses or courses created outside their scope unless a separate setting allows cloning.

When the Allow branch administrators to clone courses created on global context and parent branches setting is enabled, branch administrators can clone courses assigned to their branch and then add their own content to the cloned version.

Supervisors can also modify lessons within their branch scope, provided that their user type permissions allow it. This applies to lessons that belong to content they can manage within that branch scope.

Learning Paths can also be assigned to branches, just like courses.

Branch course visibility settings

The Branch Course Visibility setting controls how branch-assigned courses are exposed across the branch hierarchy.

This setting offers five visibility modes, allowing you to define whether a course remains limited to the current branch or becomes visible more broadly within related branches, depending on your setup.

Use this setting when you want tighter control over which branches can view and use the same course without changing course ownership.

In addition, if the supervisors can clone global courses setting is enabled in your portal, supervisors can create branch-level copies of eligible global courses and work on those copies within their allowed branch scope.

Coexistence of users from different branches

Users from unrelated branches can be enrolled in the same course. Depending on your use case, this can be useful or restrictive.

For example, a course discussion can include users from different branches without exposing unrelated branch data directly to one another. However, users in the global context may have broader visibility, depending on their role and permissions.

The same applies to reporting. A system administrator can view portal-wide information, while a branch administrator only sees the users and progress data that fall within their own branch scope.