SOURCE-CHECKED · BUSINESS DOCUMENTS

SharePoint content approval: who sees a draft, and why old files stay Approved

Understand Pending vs Approved, existing-file approval, draft visibility and version history before enabling SharePoint library content approval.

Published September 29, 2026Checked October 7, 2026Updated October 7, 2026HowCurio editorial research
An old file gains an automatic Approved marker beside a new Pending submission routed to a reviewer.
Illustration of the topic.

Turn on Require content approval for submitted items in a SharePoint library’s Versioning settings to put new submissions through a Pending approval state. Configure Draft Item Security on the same page to determine who may read unapproved content. Documents already in the library are automatically marked Approved when the requirement is enabled, without a new review of their contents.

Turn on content approval

A person with Full Control or Design permission can change these library settings. Open the intended document library, choose Settings > Library Settings, then find Versioning settings under General Settings. In the classic layout, Microsoft describes Library > Library settings on the ribbon. Set Require content approval for submitted items to Yes. Version history and Draft Item Security are separate settings on the versioning page; finish the audience selection before saving with OK.

New submissions become Pending until someone with the necessary permission approves them. A rejected document remains in the library until an authorized person manually deletes it. Rejection does not recall a copy someone already exported.

Check who can see a Pending document

Draft Item Security offers three audiences: all readers, people who can edit items, or approvers plus the document’s author. If the library allows all readers to see drafts, a Pending file may be visible to readers. Selecting approvers plus the author is a narrower intended audience, but the library owner should still check actual Read permissions; Microsoft notes that permission configuration can expose unapproved items.

Versioning also affects what readers receive. Where major and minor versions are tracked and content approval is required, the author publishes a major version before submitting it for approval. A reader without draft access sees the last approved major version. If a new document has no published major version and that reader lacks draft access, the document is unavailable to them. Use the library’s actual settings and observed version references when recording a decision; do not assume a version number from this example.

Consider the same filename viewed by two colleagues. An editor proposes a $35 allowance in a new draft of a policy whose last approved text says $40. A reader without draft access can still receive the $40 approved content. A report that “SharePoint hasn’t saved the $35 change” therefore needs the viewed version and audience to be identified before the author uploads another copy.

For a brand-new contractor policy, there is no earlier approved copy under that filename for the reader to receive. If the reader needs the currently approved travel instructions, direct them to the existing policy, while the contractor submission follows its review process. Creating another link to the unapproved file would not resolve which policy is ready to use.

Draft visibility also affects the review conversation. If every reader is supposed to comment on the proposed wording, the reader draft option supports that audience. If only the writing team needs it before submission, the editor option supports that narrower process. If only the author and approvers should see it, select that audience and examine the real file permissions alongside it. Approval status alone cannot prove the selected audience is the only one with access.

Why an old file says Approved

Suppose Travel-policy.docx was already in a library when its owner enabled content approval. Its text says employees have a $40 meal cap. SharePoint automatically marks that existing file Approved. The status does not show that a person reviewed the $40 figure during the changeover.

Now suppose someone submits a new Contractor-travel.docx with an illustrative $30 meal cap. That submission is Pending. An authorized reviewer should check the cap and the document before approving it. If the reviewer rejects it, the file remains present but is not approved. The author might then revise the illustrative cap to $35 and submit it again for review.

Those dollar amounts are fictional content in a publishing example, not travel policy advice. In this example, the older file acquired Approved automatically; the new file needs a recorded approval decision. For the old travel policy, assign an explicit review of the $40 sentence and record its actual outcome. Leave the reviewer and review date empty until that decision exists. An Approved migration state should not be relabeled as a named person’s approval simply to make the register look finished.

Keep a release record

A migration register helps prevent an automatic Approved status from being mistaken for a human decision. The content release register has five filled illustrative states and two blank reusable records: one for a migration entry and one for a review decision. The seven data rows describe the document examples above; they are not exported tenant records.

For each file, keep one current record with its library and file path, whether it existed before approval was enabled, its previous and current status, and whether Approved came from the automatic changeover or a recorded reviewer decision. Record the content fact checked, a version reference only if observed, and whether reader access was actually checked. Keep successive decisions as separate records rather than inventing historical version numbers.

Fictional document Event Approval status Evidence to retain
Travel-policy.docx Present when approval was enabled; contains the $40 example Approved automatically Mark the status as automatic, with no new reviewer decision
Contractor-travel.docx New submission contains the $30 example Pending Record the submitted content and reviewer request
Contractor-travel.docx Reviewer rejects the $30 submission Rejected Record the decision; the file remains in the library
Contractor-travel.docx Revised $35 submission Pending Record the revision and new submission
Contractor-travel.docx Authorized reviewer approves the revision Approved Record who decided and what content they checked

For the contractor revision, a useful entry is “Authorized reviewer approved the $35 allowance text” with the real version reference. “Contractor policy approved” would lose the connection to the revised content. If the earlier $30 rejection is also retained as a decision record, a later reader can distinguish the rejected proposal from the content finally accepted.

The register has a reader_access_observation field. Leave it as “Not checked” until someone with the intended reader access has opened the relevant copy. A matching status label in an author’s view provides no evidence about that other reader’s available version. The worksheet organizes the publication story; SharePoint’s own version history and your organization’s records still supply the underlying evidence.

A library owner can make the handoff specific: “Please confirm which library will require content approval, which Draft Item Security audience we selected, which files were already Approved when we enabled it, and where reviewers will record the content checked and their decisions.” That gives the team a way to distinguish inherited status from review evidence.

When the command says Request approval

SharePoint’s modern approvals are separate from content approval and request sign-off; Microsoft says these features are not integrated. A modern approval request therefore should not be treated as proof that a library document’s content approval status changed. For a publication question, inspect the library’s content approval status and version visibility directly.

Source note: This is based on Microsoft’s guidance for requiring content approval, version history, and approvals in libraries. Service documentation was checked on October 7, 2026. The policy examples are illustrative; no tenant configuration or approval was performed.