Multiple Operator Accounts or One Account with Bases? A Key Decision for Large Organisations
For a small operator with a single AOC and one OCC, setting up Leon is straightforward: one operator account, one team, one configuration. For large organisations — groups holding multiple AOCs, running dispersed offices across time zones, or supporting several fleets with separate operational teams — the very first onboarding decision is also one of the most consequential: should the organisation run on multiple operator accounts, or on one (or fewer) accounts structured internally with bases?
This decision shapes data visibility, compliance monitoring, reporting, access control, and integrations for years to come. Changing the model later is possible, but it is a migration project in its own right, so it is worth getting it right at the start. This article explains both concepts, compares the two models honestly, and gives guidance on which types of organisations tend to be best served by each.
What is an operator account?
An operator account is the fundamental unit of data in Leon. Each account has its own fleet, its own users and crew, its own flights, its own admin panel and its own configuration — FTL settings, checklists, Journey Log items, email templates, privileges, integrations, and everything else. When we talk about "an operator" in Leon, we mean exactly this: a self-contained environment.
Operator accounts are isolated by design. Core operational data — crew members, flights, duties, fleet — belongs to one account and cannot be shared with another. Leon does offer cross-operator visibility mechanisms: it is possible to configure a setup in which one operator sees, and in defined cases even edits, flights belonging to another operator (a model commonly used between trip support companies and their clients, or between commercial and management arms of a group). However, visibility is not the same as shared planning. Even with cross-operator access configured, it is not possible to schedule another operator's aircraft or assign another operator's crew member to a flight in your own account. The boundary between accounts is a hard one.
What is a base?
A base is an organisational unit defined within a single operator account. In Leon's General Settings, an operator can define any number of bases, each with its own time zone and its own OPS, Sales and Customer Service email addresses. Bases are then assigned to the building blocks of the operation:
-
Aircraft — each aircraft in the fleet can be assigned to a base in its profile.
-
Users and crew — each user profile carries a base assignment.
-
Flights — a flight can be assigned to a specific base directly in the OPS module, overriding the aircraft's default base where needed.
In practice, a base usually corresponds to a real organisational structure: a separate OCC responsible for a particular fleet, a regional office, an AOC within the group, or simply a team within a larger department. The important mental model is that a base is whatever organisational unit the operator decides it should be — Leon does not impose a definition.
Once bases are in place, they permeate the system. Views such as OPS and crew planning can be filtered by base, so that a dispatcher in one OCC works day-to-day only with their own aircraft, crew and flights. A user assigned to a base sees, by default, the schedule of the aircraft and colleagues assigned to that base. Increasingly, configuration itself can be scoped per base — for example, Journey Log items can be assigned to one or more operational bases, and email templates can use per-base reply-to addresses — while everything still lives inside one operator account.
The multi-account model: maximum separation
Choosing separate operator accounts for each entity in the group gives you the strongest possible separation Leon offers.
Strengths:
-
Hard data isolation. Crews, flights and fleet data of one entity are structurally invisible to the others unless cross-operator visibility is explicitly configured. There is no risk of a dispatcher accidentally assigning a crew member from a different entity to a flight — the system simply does not present that crew member as an option.
-
Fully independent configuration. Each account has its own FTL setup, its own checklist and Journey Log definitions, its own privilege groups, its own document and email templates. Entities with genuinely different operational cultures, regulatory regimes or branding can each get a configuration tailored precisely to them, with no compromises.
-
A natural fit for trip support. This model is particularly recommended for trip support companies working with multiple client operators who use Leon. Each client remains a separate, sealed environment; the trip support team gains visibility into client accounts where agreed, and features such as operator colour coding help differentiate one client's flights from another's. Mistakenly mixing one client's crew or data into another client's operation is structurally impossible.
Costs:
-
Group-level reporting is weak. There are no native reports spanning multiple operator accounts. Management wanting a consolidated picture of the whole group — total flight hours, fleet utilisation, crew statistics across all entities — must extract data from each account separately and consolidate it outside Leon.
-
Compliance becomes harder when resources are shared. If the same pilots fly for more than one entity, or flights on one AOC are performed on aircraft belonging to different operator accounts, each account only sees its own slice of a crew member's activity. FTL and duty monitoring loses the complete picture, and keeping compliance airtight requires manual coordination between accounts.
-
Administration multiplies. Every account is configured, maintained and administered independently. A policy change that should apply group-wide has to be replicated account by account.
The base model: one organisation, structured internally
The alternative is to consolidate the group into one operator account (or a small number of them) and use bases to reflect the internal structure.
Strengths:
-
Independent day-to-day planning with shared resources. Each base plans exclusively its own fleet and crew in its filtered view, yet flights and crew can be shared across units whenever the operation requires it. A pilot based in one unit can be assigned to another unit's flight; an aircraft can fly a rotation planned across offices. The organisational boundary exists for clarity, not as a wall.
-
Compliance across the whole organisation. Because all duties, flights and FTL data live in one account, Leon sees the complete activity of every crew member and every aircraft regardless of which base or AOC they served. For large organisations where crews and aircraft cross internal boundaries, this is the single strongest argument for the base model — it is what guarantees reliable FTL and duty monitoring.
-
Organisation-wide reporting. Report Wizard and other reporting tools operate over the entire account, so senior management gets consolidated fleet, crew and operational reporting out of the box — with base as just another dimension to filter or group by.
-
One configuration to maintain. Policies, templates and settings are managed once, in one place.
Costs:
-
Access separation is softer and takes more work. It is still possible to configure restricted access levels per unit using base filtering and privilege groups, but this separation is more limited and harder to achieve than the structural isolation of separate accounts. If a strict "unit A must never see unit B's data" requirement exists, the base model will struggle to deliver it cleanly.
-
Configuration can be more demanding. A growing number of settings can be scoped to selected bases — Journey Log items, base-specific email addresses, per-base template behaviours — but many settings remain configurable only at the operator level. Units that need genuinely divergent configurations (different checklist philosophies, different FTL regimes that cannot coexist, different document sets) may find the shared account constraining, and designing a configuration that serves everyone requires more upfront analysis than simply giving each entity its own account.
Integrations: a factor that is easy to overlook
Integrations deserve explicit attention in this decision, because many of them are configured at the operator account level and allow only a single external account to be connected. This matters most in the consolidated model: if a group runs one Leon account with several bases, but each entity holds its own account in some third-party system, an integration that accepts only one external account per operator becomes a constraint. In such cases the options are either to run the setup with multiple operator accounts for that reason, or to discuss with us extending the specific integration to support multiple external accounts.
In practice, however, this problem is largely minimised. The integrations where multi-entity organisations most commonly hold several external accounts — Avinode, PPS, ForeFlight and World Fuel Services (WKC) — already support connecting multiple accounts within a single Leon operator and mapping them to different bases. For example, an operator with more than one Avinode account can connect all of them to one Leon account. For most groups, the base model therefore does not block the key integrations.
Before committing to either model, list the integrations the organisation depends on and verify with the onboarding team how each behaves in the intended setup.
How to decide
There is no universally correct answer, but the patterns are consistent:
Lean towards separate operator accounts when:
-
You are a trip support or flight support company serving independent client operators.
-
The entities are genuinely independent businesses that never share crew or aircraft.
-
Hard data isolation between entities is a contractual, legal or commercial requirement.
-
Each entity needs a fundamentally different configuration.
Lean towards one account with bases when:
-
Crew members or aircraft are shared between units or AOCs — this is the decisive factor, because it is the only way to keep FTL and compliance monitoring complete.
-
Senior management needs consolidated, group-level reporting.
-
The units are organisational divisions of one company rather than independent businesses.
-
You want to administer one configuration rather than several.
Many large groups end up with a hybrid: one primary account with bases for the entities that share resources, and separate accounts only for the parts of the group that are truly independent. Whichever direction you take, discuss the intended structure with the Leon onboarding team early — the account and base architecture is the foundation everything else is built on.