# [ticketId]: Linking Review Work to Tickets

This page explains how the ticket identifier, shown as `[ticketId]`, connects documentation review work with the ticket that requires follow-up. Using the same ticket reference helps you keep review decisions, corrections, and publishing work organized.

## Overview

During documentation review, you may need to return to a specific ticket to clarify requested changes, confirm scope, or record follow-up work. The `[ticketId]` identifies that ticket so you can distinguish it from other review items and keep related work together.

Use the ticket reference when you are reviewing generated documentation, discussing requested edits, or preparing items for publication. It provides a consistent way to connect the review context with the issue that prompted the work.

The review area includes a **1 Review Summary** section and a **Back to Review** action. These controls help you move between the review information and the active review workspace without losing the context of the ticket you are working on.

> 📷 _Screenshot pending: Review Summary showing the ticket context used to identify related documentation review work._

## Prerequisites

Before you begin, make sure that:

- You have access to the workspace containing the documentation review.
- You know the ticket identifier you need to review, such as the value represented by `[ticketId]`.
- The relevant documentation has been generated or imported for review.
- You have permission to view the review workspace and the related ticket.
- You are ready to record any changes or follow-up work associated with the ticket.

## Step-by-Step Instructions

1. Open the workspace that contains the documentation review work.

2. Select **Review & Publish** to enter the review area.

3. Locate the **1 Review Summary** section.

4. Identify the ticket reference shown for the review item.

5. Compare the displayed ticket reference with the `[ticketId]` you were asked to review.

6. Open the related ticket in your organization’s ticket workspace.

7. Confirm that the ticket’s request matches the documentation work shown in the review.

8. Review the documentation content associated with the ticket.

9. Select **Preview** when you need to check how the documentation will appear to readers.

10. Select **Back to Review** to return from the summary or preview context to the active review workspace.

11. Record the review outcome in the related ticket according to your team’s process.

12. Return to **Review & Publish** when the documentation is ready for the next review or publishing decision.

> 📷 _Screenshot pending: The Back to Review action used to return to the active documentation review after checking ticket-related information._

## Tips and Best Practices

- Use the ticket identifier as the primary reference in review discussions. This reduces confusion when several documentation reviews are active at the same time.

- Check the ticket reference before making changes. A similar document title or feature name may appear in more than one review, while the ticket identifier provides the clearest connection to the requested work.

- Use **1 Review Summary** to orient yourself before reviewing detailed content. The summary is useful when you need to confirm what work is being reviewed and why it is connected to a particular ticket.

- Use **Preview** before marking work as ready for follow-up or publication. Reviewing the reader-facing presentation can reveal formatting or wording issues that are not obvious while editing.

- Use **Back to Review** rather than starting over from the workspace navigation when you are moving between review information and the working review. This helps preserve your current review context.

- Keep ticket follow-up specific. When you record an outcome, identify whether the work is ready to publish, needs documentation changes, or requires additional clarification from the ticket owner.

- If the ticket requires broader documentation work, use the available documentation workflow options such as **Generate Documentation →** or **Or import existing documentation** before beginning the review cycle.

## Related Pages

- [Review & Publish Documentation](#) — Review documentation and prepare it for publication.
- [Using the Review Summary](#) — Understand the information presented in **1 Review Summary**.
- [Previewing Documentation](#) — Use **Preview** to inspect reader-facing output.
- [Generating Documentation](#) — Start documentation generation with **Generate Documentation →**.
- [Exporting Documentation](#) — Use **Export Documentation** when you need to share or retain documentation outside the workspace.
- [User Guides](#) — Access user-focused documentation from **User Guides** or **📋 User Manuals**.

## Troubleshooting

### The ticket reference does not match the work you expected

Return to **1 Review Summary** and verify the ticket identifier before continuing. If the identifier still does not match, stop the review and confirm with the ticket owner which review item should be used.

### You cannot return to the review workspace

Select **Back to Review**. If the action is unavailable or does not open the expected review, return to the workspace and select **Review & Publish** again. Confirm that you opened the correct project and review item.

### You need to show the documentation to someone who cannot access the review

Select **Preview** to inspect the current output. If your workspace provides it, use **Share Preview Link** to share the preview with the appropriate reviewer. Keep the `[ticketId]` in your message so recipients can associate the preview with the correct follow-up work.