An aviation operator running aircraft out of London, Dubai, and Singapore faces a structural problem: how to give each local team a focused, manageable view of their own operation, while keeping management in command of the whole picture. Leon solves this through Operator Bases — a native organisational layer within a single account that segments users, aircraft, clients, and flights by location, without creating separate isolated systems.
Bases let each team work as if they had their own system — while the organisation retains one unified data set, one configuration to maintain, and full cross-base visibility for management.
What Is an Operator Base?
A Base is an organisational unit defined inside a single Leon account.
It can represent an OCC, a regional office, an AOC within a group, or any operational division the company defines. Each base has its own time zone — so schedules, duties, and reports display in local time — and its own OPS, Sales, and Customer Service email addresses, ensuring correspondence routes to the correct team automatically. Beyond these properties, the rest of the account configuration — document templates, integrations, and global settings — is shared across all bases, so there is no duplication of setup when a new base is added.
What Can Be Assigned to a Base?
Four key resources can be assigned per base, each with a direct effect on what users see and can act on:
-
Aircraft — Tail numbers assigned to a base appear in that base's schedule view. A planner at another base will not see them by default.
-
Crew & Users — Pilots, dispatchers, and other users are tied to a base. When logged in, they see only the aircraft and colleagues in their base.
-
Clients — A client assigned to a base means any trip they request is automatically routed to that base. Requests/Quotes lists filter accordingly.
-
Flights — Individual flights can be explicitly assigned to a base in OPS, overriding the aircraft default when needed.
How Bases Shape the Day-to-Day Work
The moment a user logs in, Leon applies their base context across every module they open:
-
Schedule (SCHED & OPS): The aircraft list shows only tails assigned to the user's base. Times display in the base time zone — no manual UTC conversion required. Switching to another base perspective is one click for users with cross-base access.
-
Crew Timeline: Crew are filtered by base, so a Warsaw dispatcher is not distracted by Dubai rosters. Crew duties are shown in the base's local time.
-
Requests & Quotes: The sales inbox shows only requests assigned to the user's base — including requests from clients whose base assignment matches. A regional sales team operates its own pipeline without interference from other locations.
-
Phonebook / Contacts: When a user creates a new contact, their base is pre-filled automatically. A contact can belong to more than one base when shared accounts or relationships span regions. Users restricted to their own base cannot assign contacts to others.
-
Management overlay: Users with cross-base privileges — typically operations directors or group managers — can switch between base views or see the full account, giving them a consolidated picture of all locations without the noise experienced by local teams.
Practical result: a dispatcher in Singapore opens Leon and sees their three aircraft, their crew, and their client requests. Their counterpart in London sees the same system configured identically — but scoped to London. Both work faster, with less noise, and with no risk of accidentally modifying another base's data.
FTL Regulations Across Different Bases
An operator running aircraft in Europe, the Middle East, and Asia-Pacific will often face different flight time limitation frameworks in each region — EU-OPS, GCAA, CAAS, or custom national regulations. Leon handles this through the AOC (Air Operator Certificate) model, which is the mechanism through which FTL regulations are applied to aircraft:
-
Each AOC in Leon carries its own full FTL configuration — maximum FDP tables, rest requirements, cumulative limits, and extended FDP rules — independently of other AOCs.
-
Each aircraft is assigned to a default AOC. When a flight is created on that aircraft, Leon automatically applies the correct FTL rules to the assigned crew.
-
Since aircraft are also assigned to bases, an operator can effectively run different FTL frameworks per base: European tails assigned to the EU-OPS AOC, UAE-registered tails to a GCAA AOC, and so on.
-
Crew positionings can be individually included in or excluded from FTL calculations by selecting the applicable AOC — useful when a crew member positions across base boundaries.
-
The FTL Calculator allows operations staff to test FDP and rest limits against a specific AOC before committing a duty, directly from the duty input screen.
The combination of base assignment and AOC assignment gives operators a clean separation: the base defines who sees what and where; the AOC defines which rules apply. Together they let a single Leon account serve as the operational backbone for a multi-region, multi-regulatory group.
At a Glance
|
What |
How it works in practice |
|---|---|
|
Time zone per base |
All times in SCHED, OPS, and crew views display in the base's local zone automatically |
|
Aircraft assignment |
Each tail belongs to a base; planners at other bases do not see it by default |
|
Crew & user assignment |
Login context limits the visible roster to the user's base; cross-base access is privilege-controlled |
|
Client / contact assignment |
Client requests auto-route to the assigned base; sales inbox stays scoped to local accounts |
|
Flight assignment |
Flights can be explicitly linked to a base in OPS for accurate workload and cost attribution |
|
FTL via AOC |
Each AOC holds a distinct regulatory framework; aircraft-to-AOC assignment drives automatic rule application per base |
|
Management view |
Privileged users switch between bases or see all — one account, full cross-base visibility |
|
Shared config |
Document templates, integrations, and global settings are maintained once for the whole account |