CAMOLOG onboarding: workflow and team roles
Onboarding starts with the existing workflow. Who receives utilisation entries, where is the component list kept, who reviews documents and how is completed work confirmed? These answers define the migration scope and the participants' responsibilities.
CAMOLOG brings together utilisation, components, limitations, documents and planning for the Mi-8/Mi-171 family. It is a browser-based system. Onboarding requires prepared source information, engineering review and an agreed process for maintaining the records afterwards.
Implementing a continuing airworthiness recordkeeping system includes migrating opening records, assigning roles and agreeing daily work. CAMOLOG helps maintain these records; it does not issue an airworthiness determination, replace the authority of an engineer or maintenance organisation, or replace required documents. Archive preparation and engineering reconciliation therefore belong in the initial scope discussion.
Define the demonstration scenario
Describe the helicopter variants and current records. File formats and the principal difficulties are enough for the first discussion; the full customer archive is unnecessary for an interface introduction.
We suggest a demonstration using prepared training information. It can cover a draft, an attached document, review of one item under the engineer role and planning for a test aircraft. This helps establish the actions your staff will perform.
If spreadsheet migration or work-order preparation is the main question, specify it beforehand. The demonstration can then follow that process, with a broader interface tour used to introduce other sections.
Agree the scope before migration
Agree the aircraft list, users, roles, document package and opening cut-off date. Discuss missing pages, conflicting spreadsheets, unconfirmed values and maintenance history separately.
A source inventory should show who supplies each item, its effective date and the person responsible for questions. It provides a basis for estimating preparation and review work.
Onboarding time depends on the quality and completeness of the sources. A reconciled archive and a collection of unrelated spreadsheets require different work. A universal one-day promise would not describe those differences.
The administrator prepares; the engineer confirms
The administrator creates a saved draft containing aircraft details, initial counters, components, limitations and the latest completions of existing maintenance checks. Preliminary XLSX/XLSM import supports column mapping and review of the resulting component rows.
Submission fixes the version. An engineer from the same organisation reviews each item and source file, confirming it or asking a specific question. The administrator can return the package for editing and submit a new version.
Earlier decisions remain in the history, but the changed package requires a new review. After all items are confirmed, the administrator enters the snapshot into the operational records. The administrative role does not substitute for engineering confirmation in this process.
Agree the daily-record boundary
The snapshot represents the end of the selected day. Daily entries start the next day. Check that historical accumulation is already included in the opening values and will not be counted again.
Verify units and starting points as well. Aircraft total time, component time and time since overhaul may describe different periods. A blank needs clarification and must not automatically become zero.
During transition, identify who reconciles totals against the sources. Resolve discrepancies against specific entries. A correction needs evidence that can be located later.
Define access and permitted actions
CAMOLOG separates data by organisation and assigns access by user role. Establish who needs operational actions and who needs viewing access, linking permissions to actual responsibilities.
Individual accounts help distinguish participants' actions. Agree how roles will be assigned and changed. Changes in staff responsibilities need to be reflected in the ongoing access process.
Aircraft logbooks, signatures and user details may contain personal information. Agree the materials, processing conditions and use of external recognition services before uploading a real archive. A technical feature alone does not establish compliance with every requirement in every situation.
Understand the current scope
The wizard supports manual entry, document upload and preliminary spreadsheet import. Automatic interpretation of every field in arbitrary scans is not supported. Directive history is handled separately with supporting evidence.
Manufacturer-library work requires the operator's access. In the current implementation, checking depends on a running session; an incomplete catalogue or lost login must remain visible as an unfinished review. Entering model and serial-number filters does not mean all documents have been obtained and assessed.
Discuss these boundaries at the start so preparation, review and ongoing responsibilities can be agreed precisely. A scenario beyond the available functionality requires separate discussion of scope and feasibility.
Subscription terms and access to the results
Pricing, support scope, timescales and renewal are set by contract. An offer requires information about the fleet, source package and work required. A single public price without that context could misrepresent the service scope.
The paid period for an aircraft is one year from the payment date recorded by the administrator. Operational actions are restricted after that period; the customer can export the aircraft archive. Review export content and continued use of the results before subscribing.
Begin with one scenario and a question list. Explain the current records, desired outcome and review participants. The demonstration then provides a basis for agreeing the package, responsibilities and onboarding terms.
This article describes a records workflow. Applicability, maintenance limits and airworthiness decisions require engineering review against the applicable documentation.
See the workflow in action
Discuss your source package and see how CAMOLOG organises the work.
Request a demo