No two handling systems use the same codes. Before FlightSort shows a single flight card, a guided process translates your database's real-world nomenclature into FlightSort's model — and verifies it against real data before letting it into production.
A flight's status codes — check-in open, boarding, gate closed, departed — aren't a standard. They're each handling system's own internal nomenclature, and it changes from one installation to the next.
Notice the RDY code in the example: in everyday operational language it sounds like "ready to go, still on the ground" — but in this particular installation it's grouped with the rest of the departure codes. Guessing that without checking real data is exactly the kind of mistake the mapping process is designed to prevent.
A guided wizard walks through the installation from start to finish. Nothing is assumed — every step can be tested against the real database before moving on.
The database engine is identified and a read-only connection is established — the same principle as the rest of the integration: FlightSort never writes to the airport's systems.
You point to where each piece of data lives — flights, check-in counters, status codes — inside that installation's real schema. The wizard automatically suggests which interface capabilities make sense to turn on, based on what it finds.
From the mapping, the procedures that feed FlightSort are generated and installed — with minimum read-only permissions, never write access.
Each installed procedure is checked to confirm it returns exactly the data shape FlightSort expects, before moving to the next step.
The wizard queries the real database and shows which status codes actually exist in that installation — not a generic list. This is where the RDY example gets resolved: against real data, not an assumed equivalence table.
Of all a flight's states, only one triggers a real alarm in FlightSort: Departed. Everything else is traceability. That's why it's the only one the wizard won't let through unverified.
Filling in the field isn't enough — the wizard checks the configuration against codes actually observed in that installation's database. A list of codes that simply don't exist there is treated exactly like an empty list: the installation stops until it's fixed.
The mapping wizard works on Oracle today, with the full flow described above. The rest of the engines are on the roadmap.
With read-only access to your database, we can show you in one session which real codes your installation has, and how they'd translate.