Bug reports and support
How to capture useful support context when a workflow fails or something looks wrong.
Help updated for v0.10.21 · 2026-07-13
When to send a bug report
Send a bug report when the app does something that blocks work, shows an error, saves the wrong data, reloads unexpectedly, loses context, prints incorrectly, or behaves differently than the workflow suggests. A bug report is especially useful when the issue happened during a real operation because it can capture the route, recent actions, timing, and last visible error while the problem is still fresh.
Do not wait until the end of the day if the screen still has the error visible. The most useful report is usually the one sent immediately after the failure. If the bug report modal can capture a page snapshot, attach it. If the workflow involved scanning, printing, uploading media, changing settings, or a specific record, describe the exact sequence so support can recreate the problem instead of guessing.
What to include
A good report says what you tried to do, what you expected, what actually happened, and whether you found a workaround. For example: “I edited a type image, chose an existing image, clicked Save, and the type update failed.” That is far more useful than “image broke” because it tells support where to start.
Include names or visible identifiers when they are safe to share: the order number, type name, Asset ID, warehouse, label template, report name, or user action. If the problem only happens for one company or one account, mention that too. The debug details already include technical context, so your note should focus on the human workflow that led to the error.
What happens after sending
A bug report is not only a support message; it is a paper trail for product quality. It helps the team connect a visible failure to recent diagnostics, logs, and workflow context. If the issue is known, it should appear in the known-issues section of the user changelog until it is addressed, so testers can tell whether a problem is already on the radar.
If a workaround exists, support should describe it in normal workflow language. If a fix ships later, the changelog should mention that the known issue was addressed. That loop matters because users should not have to remember which bugs were reported, which bugs are still open, and which bugs were fixed in the current version.