Recognizing What Each Review Status Means
In Atloria, the current review result is typically shown as a status badge on the version review screen, along with a review summary area that helps you understand where the version stands. When you open a documentation version that has been sent for review, look for the label that shows whether it is Pending Review, Changes Requested, Approved, or Rejected. That badge gives you the quickest read on what should happen next.
Each status means something different:
- Pending Review means the version has been submitted and is waiting for reviewer action.
- Changes Requested means a reviewer has looked at the version and wants updates before it can move forward.
- Approved means the version passed review and can continue to the next release step, depending on your team’s process.
- Rejected means the version should not move forward in its current form and usually needs a more substantial restart or rework before review begins again.
The most important difference is between Approved and Rejected:
- With Approved, the version is considered accepted for the current review stage.
- With Rejected, the version is not accepted, and your team should treat it as blocked until the issues behind the rejection are understood and addressed.
You can usually confirm the latest decision in the review summary and then scroll to the review history or activity timeline to see how the status changed over time. That history is useful when several people are involved. It helps you trace:
- who submitted the version
- who reviewed it
- what decision was made
- when that decision happened
If you need a refresher on how decisions are made in the first place, see Managing Version Review Decisions and Approvals.
Reading Reviewer Comments and Decision Notes
After a review decision is made, Atloria may show feedback in more than one place. Start by opening the comments panel on the version or document review screen. This is where you can read ongoing discussion, follow comment threads, and see whether a reviewer pointed to a specific section that needs attention. If the review includes inline annotations, open the marked section in the content area and read the note attached to that exact passage. For broader feedback, check the review details or review summary area for the final decision note.
It helps to separate two kinds of feedback:
- General comments are used for discussion, suggestions, and section-by-section feedback.
- Decision notes are attached to the actual review outcome, such as Approved, Changes Requested, or Rejected.
Reviewers often use comments to call out issues such as:
- missing product or feature details
- unclear instructions
- style or wording problems
- factual corrections
- sections that need stronger screenshots or examples
- content that does not match the intended audience
When you read comment threads, pay attention to whether they are still open or already resolved. In practice, this usually means:
- Unresolved comments still need a reply, an edit, or reviewer confirmation.
- Resolved comments have already been handled and usually do not need more action unless the reviewer reopens the discussion.
If Atloria shows @mentions, use them to spot comments directed specifically to you or another teammate. That is especially useful when several authors and reviewers are working in the same version.
Before making edits, compare the detailed comments with the final decision note. A version may contain many small suggestions, but the decision note usually tells you which issues are required before the version can move forward.
Deciding What to Do After an Approval
When a version shows Approved, do not assume the work is completely finished. First, confirm the approval in the status badge and review summary. Then check whether your team requires more than one reviewer. If Atloria shows multiple review decisions or a shared review summary, make sure all required reviewers have completed their part before you move the version ahead.
Next, read any final notes attached to the approval. An approval can still include follow-up items such as:
- minor copy edits
- title or metadata cleanup
- screenshot replacement
- audience checks
- final publishing verification
These notes do not usually block approval, but they may still need to be completed before release. If your team tracks release readiness separately from review approval, use the approved result as a signal to move the version into the next stage your team uses, such as Ready to Publish or Scheduled. The exact label depends on your content workflow, but the key point is that Approved means the review stage has been passed.
You should also review the activity timeline or history area so the sign-off is clearly visible. This record helps documentation managers and project leads confirm that the version received formal approval and shows:
- who approved it
- when the approval happened
- whether any final notes were added
If the version is approved but you still need to prepare it for release, the next step is usually not another round of editing. Instead, you move into release preparation tasks. That handoff becomes easier when the approval note, comment resolution, and status history are all complete and easy to read.
Revising a Document After Changes Are Requested or Rejected
If the status badge shows Changes Requested or Rejected, start by identifying which of those two outcomes you are dealing with. They both stop the version from moving forward, but they usually mean different levels of rework.
Use Changes Requested when the version is still on the right track but needs updates before approval. In that case, open the comments panel, review any inline annotations, and read the decision note in the review summary. Build a revision checklist from what reviewers flagged, focusing first on items that clearly block approval, such as missing sections, incorrect instructions, or unsupported claims.
Use Rejected as a stronger signal that the current submission should not continue in its present form. A rejection often points to a bigger problem, such as the wrong scope, the wrong document type, or a draft that is too incomplete for review. Read the rejection note carefully before editing so you do not spend time polishing a version that needs a more fundamental rewrite.
As you revise the draft in Atloria, work through the feedback methodically:
- update the affected content
- correct the sections named in comments
- reply in comment threads where clarification is needed
- resolve threads once the issue has been fixed
- double-check that previously flagged sections now match reviewer expectations
After the updates are complete, make sure you resubmit the version for review. Saving changes alone does not mean the review has restarted. If the original workflow included a Submit for Review action or similar review control, use that same submission path again so reviewers can see the version is ready for another pass.
Coordinating Reviewer and Author Responsibilities
A smooth review cycle in Atloria depends on reviewers and authors using the right actions at the right time. On the review screen, reviewers are responsible for making the decision that best matches the state of the version. That usually includes:
- leaving comments in the comments panel
- adding inline annotations to specific sections
- choosing Changes Requested when the version is close but not ready
- choosing Approved when the version meets expectations
- choosing Rejected when the submission should not continue as submitted
Authors have a different set of follow-up responsibilities. Once feedback appears, the author should:
- read the review summary and final decision note
- respond to open comment threads
- revise the draft content
- resolve comments that have been addressed
- resubmit the version for review when updates are complete
- advance approved content into the next release stage when all approvals are in place
For documentation managers, the focus is usually broader. Instead of looking at one version at a time, they monitor review progress across many items using the review queue, status filters, or activity tracking views. These views help them spot bottlenecks, such as versions stuck in Pending Review or drafts that remain in Changes Requested without being resubmitted.
Choosing between Changes Requested and Rejected matters. Teams usually use Changes Requested when the draft is valid but needs correction. Rejected is more appropriate when the submission is fundamentally unsuitable, such as:
- the wrong document was submitted
- the content is out of scope
- the draft is too incomplete for meaningful review
- the version does not match the intended release
Clear use of these decisions keeps the review queue easier to manage and prevents confusion for authors.
Handling Common Review Outcome Problems
Sometimes the status and the actual workflow do not seem to match. When that happens in Atloria, start with the visible review details rather than guessing.
If the version shows Approved but does not move forward, check whether there are still additional required reviewers who have not completed their decision. Also review the review summary and activity timeline for signs that approval happened in one part of the workflow, but another required step is still waiting. A single approval does not always mean the entire review process is finished.
If comments are present but the outcome is unclear, compare the detailed feedback in the comments panel with the final note attached to the review decision. Inline comments may include suggestions, questions, or optional edits, while the decision note usually tells you the official result. When the two seem inconsistent, rely on the visible status badge first and then use the final decision note to understand the reviewer’s intent.
If an author updates the draft but the status still shows Changes Requested, the most common reason is that the version was edited but not formally resubmitted. Open the review controls and make sure the version was sent back through the review action, not just saved in the editor.
If a reviewer used Rejected without enough explanation, open the activity history and all related comment threads to gather context. Look for:
- earlier comments that explain the concern
- unresolved threads tied to major issues
- a short rejection note that needs to be interpreted alongside prior feedback
If the reason is still unclear, pause before restarting review. It is better to clarify the rejection through the existing discussion than to submit another version that repeats the same problem.
Overview
In Atloria, understanding review outcomes is less about memorizing labels and more about reading the full review picture on the version screen. The status badge tells you the current state, the review summary explains the latest decision, and the comments panel shows the detailed discussion behind that result. When you use those three areas together, it becomes much easier to decide whether to move forward, revise the draft, or restart the submission.
The main review outcomes you will see are:
- Pending Review
- Changes Requested
- Approved
- Rejected
Each one points to a different next step. Approved means the version can continue into the next release stage. Changes Requested means the draft should be updated and sent back for review. Rejected means the current submission should not continue without more substantial correction or repositioning. The activity timeline helps confirm who made the decision and when, which is especially useful when multiple reviewers are involved.
This guide focuses on interpreting those outcomes after review has already happened. If you need help with the decision process itself, use Managing Version Review Decisions and Approvals for the earlier part of the workflow.
Once you are comfortable reading statuses, comments, and decision notes, the next step is preparing an approved version for release readiness. Continue with Preparing a Version for Final Release Review.
Prerequisites
Before using the review details in Atloria, make sure you already have access to a documentation version that has been submitted into the review workflow. This guide assumes you can open the version review screen and see the main review areas, such as the status badge, review summary, comments panel, and activity history.
You will get the most value from this guide if the following are already true:
- you can open the relevant project and documentation version
- the version has already been submitted for review
- at least one reviewer decision, comment, or note is visible
- you understand the basic review flow used by your team
It also helps if you have already worked through Reviewing and Approving Documentation Versions and Managing Version Review Decisions and Approvals. Those guides explain how reviews are initiated and how reviewers record decisions. This guide picks up after that point and focuses on how to interpret what happened and what to do next.
If you are an author, be ready to edit the draft, respond to comments, and resubmit the version when needed. If you are a reviewer or documentation manager, be ready to read the review summary, compare comments with the final decision, and confirm whether the version should advance or return to editing.
Was this page helpful?