Skip to content
  • There are no suggestions because the search field is empty.

Defect Synchronization

Defect synchronization connects defect information between FlightLogger and FlightLogger Maintenance.

This is useful when defects are reported during flight operations and need to become part of the maintenance workflow. A defect may start as an operational report, but once it enters FlightLogger Maintenance, it must be handled as a maintenance item.

Defects can create maintenance demand, support planning, and link to work orders. They are not the same as work execution.

What defect synchronization is used for

Defect synchronization can be used to bring pilot-origin or operational defects into FlightLogger Maintenance.

Depending on your configuration, it may support:

  • Reading defects for an aircraft
  • Creating defects for an aircraft
  • Bringing FlightLogger-origin defects into FlightLogger Maintenance
  • Preserving reporter information where available
  • Supporting maintenance planning from operational defects
  • Linking defects to work orders
  • Tracking defect status in the maintenance workflow

Defect sync helps reduce manual re-entry and ensures that reported operational issues can be reviewed by maintenance users.

Defects are a source of work

A defect is an issue, discrepancy, or fault found on an aircraft.

In FlightLogger Maintenance, defects are a source of maintenance work. They may lead to assessment, deferral, rectification, closure, or work order creation.

A defect is not the same as a work order.

A defect describes the problem or discrepancy. A work order controls the planned and executed maintenance work.

Supported defect API endpoints

The defect API supports:

  • Reading defects for an aircraft
  • Creating defects for an aircraft

The supported endpoints are:

  • GET /api/v1/aircraft/{call_sign}/defects
  • POST /api/v1/aircraft/{call_sign}/defects

The integration must have the required OAuth scopes.

For example:

  • defects_read is required to read defects.
  • defects_write is required to create defects.

Aircraft matching

Defects are linked to aircraft.

Before a defect can be synchronized, FlightLogger Maintenance must identify the correct aircraft.

The defect API can find aircraft by:

  • Call sign
  • Registration
  • Aircraft ID

If the aircraft cannot be found, the defect cannot be created for that aircraft.

Before troubleshooting defect sync, always confirm aircraft matching first.

Defect payload

Defect writes use a top-level defect object.

The defect payload may include information such as:

  • External defect ID
  • Description
  • Severity
  • Reported date and time
  • Due date
  • Reporter ID
  • Reporter email
  • Reporter name
  • Aircraft registration
  • Aircraft call sign
  • Flight number

The exact data depends on what the sending system provides.

Due dates

A defect payload may include a due date.

The API supports both due_date and dueDate.

A due date may be relevant when a defect has already been deferred against a date or needs to be tracked with a specific time-based requirement.

Maintenance users should still review the defect in FlightLogger Maintenance and handle it according to the maintenance workflow.

Reporter information

Inbound defect sync may create or reuse a reporter user record for attribution.

This helps preserve information about who reported the defect.

However, this does not grant account membership or account access.

Reporter attribution and user access are separate concerns.

Defect matching is best-effort

Defect matching between systems is best-effort.

This is one of the most important things to understand about defect synchronization.

An external defect ID should not be treated as a guaranteed permanent upsert key.

This means that defect sync may try to match incoming data to an existing defect, but users should not assume that every external defect ID will always map perfectly to one and only one internal defect record in all situations.

If duplicates or unexpected matches occur, review the defect data and sync logs carefully.

Defect statuses

In FlightLogger Maintenance, defects can move through maintenance statuses.

Supported defect status concepts include:

  • Open
  • Deferred
  • Rectified
  • Closed

The exact status workflow depends on the defect and how it is handled by maintenance users.

A synchronized defect should be reviewed and managed as part of the maintenance process.

FlightLogger to FlightLogger Maintenance

Pilot-origin defects can enter FlightLogger Maintenance from FlightLogger.

Once in FlightLogger Maintenance, the defect can be assessed by maintenance users.

From there, users may:

  • Review the defect
  • Confirm aircraft context
  • Set or review due information
  • Defer the defect if appropriate
  • Create or link work
  • Rectify the defect
  • Close the defect according to the maintenance process

FlightLogger provides the operational input. FlightLogger Maintenance controls the maintenance handling.

FlightLogger Maintenance to FlightLogger

Defect sync can also involve selected outbound flows from FlightLogger Maintenance to FlightLogger, depending on configuration.

However, outbound sync is selective.

Do not assume that FlightLogger receives a full mirror of all defect-related maintenance history, work orders, repair details, technical records, or compliance documentation.

Defects and work orders

A defect may lead to a work order.

The defect describes the issue. The work order describes the maintenance work that should be planned, released, executed, completed, and closed.

This distinction matters because resolving a defect is not just a data sync event. It is part of the maintenance process.

What defect sync does not do

Defect synchronization does not automatically complete the maintenance workflow.

It does not replace:

  • Maintenance assessment
  • Defect review
  • Deferral decision
  • Work order planning
  • Workshop execution
  • Signoffs
  • Technical records
  • Compliance documentation

Defect sync helps bring defect information into the maintenance system. Maintenance users are still responsible for handling the defect correctly.

Before enabling defect sync

Before relying on defect synchronization, confirm:

  • Aircraft are correctly matched
  • Call sign and registration values are consistent
  • OAuth scopes are configured correctly
  • The integration has defects_read or defects_write as needed
  • FlightLogger Sync or OAuth setup is configured as required
  • Users understand how synchronized defects should be reviewed
  • There is a process for handling duplicates or unexpected matches
  • Maintenance users know when to create work orders from defects

How to verify defect sync

After defect sync is configured, test the workflow carefully.

Check:

  • The defect appears on the correct aircraft
  • The description is correct
  • Severity is mapped as expected
  • Reported date/time is correct
  • Reporter information appears as expected
  • Due date appears if provided
  • The defect status is appropriate
  • The defect does not duplicate an existing record unexpectedly
  • Sync logs do not show errors

Verification is especially important before go-live.

Common defect sync issues

If defects do not appear as expected, check:

  • Is the aircraft matched correctly?
  • Does the aircraft exist in FlightLogger Maintenance?
  • Is the call sign or registration correct?
  • Does the integration have the correct defect scope?
  • Is the payload using a top-level defect object?
  • Does the defect contain the required information?
  • Is the defect already present under another match?
  • Are sync logs showing a failure?
  • Is the user viewing the correct account?
  • Is outbound sync expected, or only inbound sync?

If defects appear duplicated, review matching assumptions and external IDs.

Best practices

  • Verify aircraft matching before testing defects.

  • Use clear defect descriptions.

  • Preserve reporter information where possible.

  • Do not rely only on external defect ID for matching.

  • Review synchronized defects before creating work.

  • Train maintenance users to distinguish defects from work orders.

  • Monitor sync logs during onboarding.

  • Investigate duplicates early.

  • Document how defects should move from report to maintenance action.

  • Remember that defect closure and repair handling belong in FlightLogger Maintenance.

Summary

Defect synchronization helps bring operational defect reports into FlightLogger Maintenance.

Defects can come from FlightLogger, but once they are in FlightLogger Maintenance, they become part of the maintenance workflow. They can be assessed, deferred, linked to work, rectified, and closed.

Defect matching is best-effort, so users should review synchronized defects carefully. FlightLogger can provide operational defect input, but FlightLogger Maintenance remains responsible for maintenance handling, repair closure, and related records.