How to send useful Army Flight Logbook feedback

Start with the task you were trying to complete

A useful report begins with the goal: locating an imported record, checking a date range, or understanding a summary. Describe what you expected and what happened instead. “The total looks wrong” is a starting point; identifying the period and filter state makes it possible to investigate.

The developer’s public discussions include requests about aircraft labels and reporting filters. They show why a concrete task is more useful feedback than a general request for more features.

Include the environment and sequence

Record whether you were using the web, iOS, or Android version, along with the app version and device type. Explain the actions in order. Mention whether connectivity or syncing was involved, and whether the issue repeats after returning to the same view.

• Goal: what you were trying to do.
• Steps: the shortest sequence that shows the issue.
• Expected result: what you thought would happen.
• Actual result: the message or behavior you observed.
• Context: platform, version, filters, and connection state.

Keep private data out of public feedback

Public posts are useful for general ideas, not for exposing account details or operational records. Remove personal and sensitive information from any screenshot before sharing it. Use the product’s support channel for account-specific issues, and follow your organization’s rules about what information may be sent.

Separate a bug from a feature request

For a bug, explain the unexpected behavior. For a feature request, explain the recurring task and why the current approach is difficult. Avoid promising yourself a release date based on an acknowledgment. A clear request gives the team evidence to evaluate; it does not establish a delivery commitment.