Multi-Branch LMS Management: A License Pool Guide | Qulak

A holding company's learning operation has several more layers than that of a single-company structure. While headquarters wants to track shared curricula and mandatory training, group companies manage their own goals and branches oversee day-to-day operations. When these layers come together in the same LMS, the first question is usually: In whose name will the license be assigned, and what will each manager be able to see?

The answer is not simply a matter of knowing the total number of users. Multi-branch LMS management requires designing the organizational tree, branch quota, centralized license pool, role-based visibility, and user lifecycle together. How this flow could be set up with Qulak is validated during discovery, based on the institution's current plan, contract, integrations, and information security requirements.

Why does multi-branch LMS management require a centralized license pool?

Setting up separate license packages for each branch may seem organized at first. However, temporary assignments of employees across companies or locations, the opening of new branches, and the addition of seasonal teams can quickly put this arrangement under strain. While seats go unused in one branch, another may request additional licenses. This makes it harder to understand where capacity is available and where it is constrained.

With a centralized license pool approach, total capacity is tracked at the group level. Beneath that, for each branch, a target quota, warning threshold or limit requiring approval can be defined. These should be considered operating options that can be designed on Qulak after validating the institution's current plan, not as definitive product features.

How should branch quotas be designed?

It is not sound practice to base quotas solely on the current number of employees. Hiring plans, positions with high turnover, mandatory training coverage, and locations scheduled to open in the near future should also be taken into account. The goal is not to confine every branch to a narrow number, but to make capacity usage predictable.

In practice, three different quota approaches can be used together. A fixed quotaoffers a clear limit for small units with well-defined budgets or capacity. A flexible quotais a model that allows a branch to temporarily accommodate more users if there is spare capacity in the centralized pool. An approved overage routes a request to a headquarters or group company manager when a quota is exceeded. Which approach to use with Qulak should be determined based on the institution's license agreement and operating rules.

Documenting the quota policy is just as important as the technical settings. Managers should have clear answers to questions such as “What happens when the quota is reached?”, “When does an unused license return to the pool?”, “How is the previous record closed when someone changes branches?” and “Who can use the central reserve?” This turns license management from person-dependent email traffic into an auditable process.

Permissions and visibility model for a holding company

Giving all managers the same view in a multi-company structure does not make operations easier; on the contrary, it can create unnecessary data visibility. A safer approach is to consider the organizational tree together with roles and scope. In NIST's RBAC approach, permissions are assigned to roles rather than distributed individually to users; users are assigned roles appropriate to their responsibilities. How this approach should be adapted to a holding-company LMS should be validated against the institution's role catalog and security policy.

In this model, “being able to view” and “being able to change” are not the same thing. A manager at headquarters may be able to read a consolidated usage report but not change users in every branch independently. Similarly, a branch manager may be able to assign training but not increase the license quota. The role matrix designed on Qulak should assess these distinctions separately at the menu, report, user, and action levels.

The organizational tree also determines how employee movements are handled. When someone changes branches, the target branch's quota and role should first be validated, then the new relationship established, and finally the old relationship closed. Microsoft's group-based licensing documentation also describes a similar transition sequence to reduce the risk of service interruption: first add to the target group, verify the assignment, and then remove from the source group. This is not a claim about definitive product behavior for Qulak; it is a general control principle to consider when designing transitions.

Turn the license lifecycle into an operational flow

The value of a centralized pool emerges not only when licenses are assigned, but also when they are reclaimed. Connecting a new hire to the correct company and branch, updating their role when their responsibilities change, reviewing an account that has been inactive for a long time, and revoking access for someone who has left are all parts of the same lifecycle.

1. Define: Create a shared data dictionary for companies, branches, departments, cost centers, and user types.
2. Authorize: Document the scope in which each role can manage users, catalogs, reports, and license operations.
3. Verify the assignment: Before assigning a license to a new user, check the branch quota, mandatory training coverage, and legal basis for data transfer.
4. Monitor: Periodically report on the total pool, branch usage, pending approvals, failed assignments, and idle accounts.
5. Reclaim: Close previous assignments after a branch change or departure; record exceptions.

Some steps in this flow can be automated through API or HRIS synchronization, while others may require human approval. Which integrations and automations can be used under Qulak's current plan should be validated alongside the institution's systems during technical discovery. API and HRIS Integration Guideoffers a complementary framework for teams that want to consider this lifecycle alongside their existing HR systems.

Data security and KVKK controls

Branch-based reporting may include personal data such as employee names, email addresses, roles, training status, or exam results. According to KVKK's official explanations on the processing of personal data, the institution should assess which data is processed, for what purpose, and under which legal condition. Therefore, when designing the license management screen, it is not enough to say “the manager can see it”; the questions why do they need to see it, and can the same purpose be achieved with less data? must also be answered.

KVKK's personal data pageexplains that explicit consent should not also be obtained where processing conditions other than explicit consent can be applied. The explanation on explicit consent states that consent must relate to a specific subject, be based on information, and be given freely. These principles are particularly important for additional data processing steps such as user verification, face verification, or sensitive reporting, rather than for license assignment itself.

For example, if a login or exam flow involving face verification is planned, explicit consent and the privacy notice should not be conflated; where possible, an alternative verification method should be offered, data minimization applied, a retention period set, and results should not be converted into automated decisions without human oversight. The announcement of KVKK's Principle Decision No. 2026/347 dated February 18, 2026, also emphasizes that the obligation to inform is not subject to consent and that, where explicit consent is required, the two texts must be prepared separately. Legal and information security teams should be consulted before implementation.

How can you validate a model suited to your organization with Qulak?

A productive discovery meeting does not begin and end with the question, “How many licenses are there?” First, how the organization operates is mapped out. Then it is determined when a license will be assigned, under what circumstances it will return to the pool, and which reports will be available to which managers. This ensures that the technical configuration aligns with real operations, independently of purchasing assumptions.

Coming to the meeting with the following information can speed up the process: company and branch hierarchy, approximate user types, the distinction between shared and local training, quota or budget rules, HRIS/SSO expectations, report scope, temporary user scenarios, and data retention policy. With Qulak, a centralized license pool and multi-branch structure can be designed; the definitive features, limits, and integration scope are validated according to the institution's current plan.

Frequently Asked Questions

Related Guides