Report a useful issue

Collect enough context for support without sharing secrets or unnecessary private data.

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 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.