Choose the right report type
Start a review session or an authorized extension review.
Choose the annotation tool, select the point/element or diagnostic entry, and enter a clear title.
Describe what happened, what should happen, and the steps that led to it
Set severity, assignee, and other fields you are permitted to change.
Choose public or internal visibility where your role permits it, submit, and open the saved report to confirm its page/version and evidence.
| Type | Use it for |
|---|---|
| Point | A problem at a position on the page, without attaching the report to a specific DOM element. Drag an area to record a rectangular region instead of a single point; both are location-based reports. |
| Element | A problem with a button, field, or other element. Select the element before submitting. |
| Console | An error or message. Open console evidence, select the entry, and create the report from that context. |
| Network | A failed or unexpected request. Open network evidence, select the request, and report it with its request context. |
What evidence a report can contain
Evidence depends on what was captured before the report and which capabilities were enabled. It may include a screenshot, nearby recorded activity, console logs, requests, element context, and source attribution. A report does not promise all logs from the entire session or a universally exact capture instant.
Check the screenshot's state and whether it is a reporter capture or an automated capture. A queued, failed, expired, or missing image is different from a successful screenshot. Accurate screenshot capture can require browser permission.
Use Replays for recorded activity, the frontend SDK for supported element source context, and backend evidence for the server request. Enabling capture later does not add uncaptured history to an old report.
Visibility and comments
Clients and guests can see public reports in their permitted review context, including reports created by other people. Do not use public visibility for staff-only details.
Internal annotations/comments are staff workflows for project owners, developers, and testers according to effective access. Clients and guests do not gain access to internal comments by being the original reporter.
Use public comments for reviewer discussion and internal comments for restricted staff context. Attachments and copied evidence can themselves contain sensitive application data.
Status, assignment, and verification
Open means the issue needs attention. In Review means it is being assessed. Resolved records a workflow decision; it does not prove a patch was applied or human verification passed. Reopened records that the issue needs more work. Won't Fix requires an explanation.
Developers may submit a status request for approval rather than immediately changing the status; tester/owner authority and configured workflow rules differ. Check the pending result and approval queue instead of repeatedly submitting the same change.
Configure severity deadlines and SLA settings in Project Settings → Workflow → Annotation Workflow. For the complete issue-management and sign-off process, use Managing Annotations and Verification.
