Preparing Versions for Review and Approval

Checking that the version is ready to send for approval

Before you use Review, Submit for Review, or Request Approval, open the version workspace and confirm you are working in a version that is still editable. If the status badge already shows an in-progress review state, a locked state, or another non-editable state, finish those steps first before trying to submit again. The goal here is simple: reviewers should receive a version that is complete enough to evaluate, not one that still needs basic cleanup.

Start in the version details area and check the fields reviewers rely on to identify the release. Make sure the version title is correct and easy to recognize. Confirm the owner is assigned so reviewers know who is responsible for follow-up. If your version screen includes a status, category, or similar details panel, fill those in before moving forward. Missing details can stop the approval action or create confusion once the request appears in the review queue.

Next, look at the page list, table of contents, or navigation tree for the version. Every required page should be present, named clearly, and placed in the right order. If a section is still missing, do not send the version yet. Reviewers should not have to guess whether a page was intentionally removed or simply forgotten.

Finally, scan for unfinished writing markers. Remove visible TODO text, placeholder copy, empty headings, and blank sections. If a page contains a heading with no body text underneath it, fill it in or remove it. If a section is not ready, it is better to hold the version than to send an obviously incomplete draft.

Reviewing the version for completeness before submission

Once the version details look correct, open the content itself and read it the way a reviewer will. Use the version preview or editor to move page by page through the documentation. Look for missing headings, unfinished paragraphs, awkward formatting, and places where body text stops abruptly. A version can look complete in the page list while still containing half-finished content inside individual pages.

1. Open the version preview or editor.
2. Move through each page in the navigation tree or page list.
3. Check that headings appear in a sensible order and that each section has complete body text.
4. Confirm pages are arranged correctly in the navigation so reviewers see the intended reading flow.
5. Remove draft-only pages that should not be part of the review.

Pay close attention to linked content. Images should display properly, attachments should be available if they are part of the page, and internal cross-references should lead to the right place. If Atloria shows a missing asset warning or a broken reference, fix it before submission. Reviewers should be evaluating the documentation itself, not reporting obvious file problems.

Also review the approval-facing notes attached to the version. If your version includes fields such as summary, change notes, or revision comments, update them so they clearly explain what changed. A short, accurate summary helps reviewers focus on the right pages and understand whether they should expect a minor update, a structural rewrite, or a release-ready version.

If you need a refresher on the broader review process, use Requesting and Completing Version Reviews alongside this preparation step.

Resolving obvious issues that would block review

Before you submit, clear anything in Atloria that is already flagged as a problem. If the version details panel, editor, or publishing area shows validation messages, warning banners, or issue indicators, treat those as blockers until proven otherwise. Sending a version with visible errors usually leads to an immediate request for changes instead of a meaningful review.

Start with required-field warnings. If Atloria highlights missing information in the version details or workflow form, fill those fields first. Then review any inline alerts inside pages. These may point to formatting problems, incomplete content, or other issues that are already visible before a reviewer opens the version.

Use any quality check, validation banner, or issue list available in the version workspace to clean up common content problems, such as:

• Broken links
• Missing images or attachments
• Missing alt text
• Empty sections
• Content warnings shown in the editor
• Open comments that still need action

Open comments deserve special attention. If a comment is marked open, pending, or needs changes, resolve it before formal review whenever possible. Reviewers should not spend time re-reporting issues your team already knows about. If a comment cannot be resolved yet, make sure the reason is documented clearly in your submission note so reviewers understand the limitation.

After fixing the issues, save the version and check the status indicators again. The page list, version header, and any warning banner should no longer show blocking problems. If the review action is still unavailable, return to the details panel and look for a missed field or unresolved alert.

Submitting the version into the approval flow

When the version is complete and the obvious issues are cleared, you can move it into review. In Atloria, this action usually starts from the version header or a workflow actions menu. Look for Review, Submit for Review, or Request Approval. The exact label may vary by workspace, but the purpose is the same: you are sending the current version to named reviewers or approvers.

1. Open the version you want to submit.
2. Click Review, Submit for Review, or Request Approval in the version header or workflow actions menu.
3. Choose the required reviewers or approvers if Atloria asks you to assign people.
4. Add a note in the message or comments field.
5. Confirm the submission and watch for the status change.

If Atloria shows a reviewer picker, select the people responsible for the next decision. If your team uses staged approvals, complete each required selection in the approval setup before confirming. Do not leave reviewer fields blank if the workflow expects named participants.

Use the submission note to guide the review. This is the best place to call out major changes, known limitations, or pages that need extra attention. Keep it practical. For example, mention that the navigation was reorganized, several screenshots were updated, or one section still needs a final legal check. A clear note reduces back-and-forth once the review begins.

After submission, confirm that the version status badge changes from an editable state to something like In Review or Pending Approval. Also check the activity timeline if it is available. You should see the review request recorded there, which helps confirm that the workflow started successfully.

Understanding what reviewers will see during approval

It helps to know what the approval screen looks like from the reviewer side, because that tells you what needs to be clean before you submit. Reviewers are typically looking at the rendered version content, the version status badge, and a set of version details that explain what they are approving. If those areas are incomplete or unclear, the review slows down quickly.

On the review screen, approvers will usually see the submitted content as readers see it, not just raw draft text. That means page order, headings, images, and linked content all matter. If a page is missing from the navigation or appears in the wrong place, reviewers will notice it immediately. They may also see a metadata panel with fields such as the version title, assigned owner, summary, change notes, revision comments, and current workflow status.

Reviewers may also have access to approval history or recent workflow activity. This helps them understand whether the version has already been revised, whether someone requested changes earlier, and who is currently responsible for the next step. If your submission note is vague, reviewers may rely on that history to piece together what changed.

Comments and comparison tools are especially important during approval. If Atloria shows annotations, unresolved comments, or a comparison view between versions, reviewers can use those areas to spot unfinished work and recent edits. A version that still contains open issues will look less ready, even if the main pages read well.

From their workflow panel, reviewers may be able to:

• Approve
• Request changes
• Reject
• Leave comments or notes

For a deeper look at how those decisions are handled after submission, see Managing Version Review Decisions and Approvals and Understanding Version Review Statuses Comments and Next Steps.

Fixing common problems before reviewers see the version

A few common problems can stop the approval process before it starts. The first is missing required information. If Submit for Review or Request Approval does nothing, or if Atloria shows an error message, return to the version details panel and check for empty required fields. The version title, owner, and any required workflow fields should be filled in before you try again.

Another common issue is that the approval action is unavailable because the version is not in the right state. If the version is already under review, locked, or otherwise not eligible for editing, Atloria may hide or disable the submission action. In that case, check the status badge in the version header and the activity timeline to see whether the version has already been sent or whether another step must be completed first.

You may also hear from reviewers that pages are missing, images are broken, or content looks outdated. This usually means the wrong version was submitted or recent edits were not saved before the review request was sent. Open the submitted version directly and compare the page list, content, and assets against what you intended to send. If needed, withdraw or update the version using your team’s normal review process before asking reviewers to continue.

If assigned approvers do not receive the request, check the reviewer selection carefully. A missing assignee, incomplete approval routing, or skipped workflow step can leave the version in review without reaching the right people. Reopen the workflow details and confirm the correct reviewers are listed.

Common checks before resubmitting:

If the version is ready and the workflow is clear, continue with Requesting Review and Handling Version Decisions.

Overview

Preparing a version for review in Atloria means doing more than clicking Submit for Review. You are making sure the version is complete, readable, and clearly explained before it reaches the people responsible for approval. That preparation happens in three places: the version details panel, the content itself, and the review workflow controls.

The version details panel gives reviewers the context they need. This is where they identify the version by title, see who owns it, and read any summary or revision notes that explain what changed. The content area shows whether the documentation is actually ready to review, including page order, headings, images, and linked references. The workflow controls move the version from an editable state into a formal review state, where approvers can comment, request changes, or approve it.

This guide focuses on the checks you should complete before reviewers get involved. It does not repeat the full review cycle or decision handling steps covered in Requesting and Completing Version Reviews. Instead, it helps you avoid preventable problems such as incomplete page lists, unresolved comments, missing metadata, and blocked submission actions.

Use this guide when you have already drafted or updated a documentation version and want to make sure it is ready for formal review. If you prepare the version carefully, reviewers can focus on the quality of the documentation rather than basic cleanup. That usually leads to faster decisions, clearer feedback, and fewer avoidable review rounds.

Prerequisites

Before you prepare a version for approval in Atloria, make sure these basics are already in place:

• You can open the project and access the version workspace.
• The version already exists and is still in a state that allows editing.
• The main documentation pages for the version have been created or updated.
• You can view the version details panel, page list, and content editor or preview.
• You know who should review or approve the version once it is submitted.

It also helps if you have already completed the earlier review preparation work covered elsewhere in the Version Review set. In particular, this guide assumes you are not starting from a blank version. You should already have content ready for review and a general understanding of how review requests work. If you need that foundation first, read Requesting and Completing Version Reviews.

Have the following information ready before you submit:

• A clear version title
• The correct owner assignment
• Any summary, change notes, or revision comments your team expects
• A final check of page order and included content
• Any notes reviewers should see about known limitations or special review focus

If your team uses screenshots, linked files, or cross-references, make sure those items are already in place before opening the approval form. Reviewers should receive a version that reflects the intended reading experience, not a draft that still depends on missing assets or unresolved comments.