# Report a useful issue

A useful report identifies the action, the object, the observed outcome, and what you expected. It should make the problem reproducible without requiring a copy of your entire workspace.

## Include

- The page or feature, item name, and safe resource identifier.
- The time and timezone when the action occurred.
- The action you chose and the relevant visible error.
- A workflow run, operation, import, transfer, or generation identifier when available.
- Whether the result is failed, still running, partially completed, or uncertain.
- Whether another tab or person edited the same item.
- Browser and screen-size context for a presentation or keyboard issue.

Settings' About card can identify the application version when requested. A screenshot can show the relevant control or error, provided it does not disclose private data that the recipient should not receive.

## Exclude

Do not include passwords, API keys, stored credential values, authentication cookies, public share-link tokens, or complete private agreements merely to illustrate an error. Replace business data with a small representative example where possible. Redact names and values unrelated to the problem.

## Avoid changing the evidence

If an operation's outcome is uncertain, retain its identifier and inspect it before recreating the item or retrying. Repeated runs can obscure which attempt produced a result. Preserve the source revision and selected run while investigating a citation or data-quality issue.

Use [troubleshooting](/docs/troubleshooting/overview) to identify the appropriate object before sending the report. A notification failure and the workflow it describes should be reported as separate observations when their states differ.