Notion vs SharePoint for policies: keep drafts out of the handbook

Notion works well when a policy is a living explanation that an owner regularly maintains. A Microsoft 365 SharePoint library is the stronger fit when the policy is a Word or PDF file that needs a controlled publication process and employees must see an approved version while a replacement is drafted and reviewed. SharePoint can separate those versions through content approval, major and minor versions, and draft visibility settings. Those controls must be configured; approval does not establish that the policy is correct or compliant.

A draft replacement must be distinguishable from the rule employees currently follow. Consider a fictional equipment reimbursement policy: the current cap is $150, and an owner proposes raising it to $200. Employees should continue to find the $150 rule while the proposed wording is under review.

Write the rule employees need

The policy needs enough context to make each version usable. For this example, its header could identify OPS-014, list Operations as owner, record approval by the Finance lead when that approval actually occurs, state the effective date, and name employees buying equipment for work as its scope. The body should state the cap, the receipt requirement, and that employees can contact Operations with questions. A superseded version should remain identifiable.

The current approved paragraph might read:

Employees buying equipment for work may request reimbursement of up to $150 per purchase with a receipt. Contact Operations with questions about eligibility.

The proposed replacement might read:

For equipment purchased on or after November 1, employees may request reimbursement of up to $200 per purchase with a receipt. Purchases made before November 1 remain subject to the $150 cap. Contact Operations with questions about eligibility.

The amounts, dates, and policy are invented for this example. The purchase-date sentence resolves a question an approver could reasonably raise: “Confirm whether items purchased October 31 follow the old rule; add the transition date before approval.”

Approval and the effective date answer different questions. If the replacement becomes visible before November 1, its text must clearly say when the new cap begins. Alternatively, the owner can choose to publish it on the intended date. Neither approach implies that approval automatically schedules publication.

Set up SharePoint before adding drafts

Start with an empty or restricted policy library before loading unreviewed files. In a modern Microsoft 365 library, an administrator with the required Full Control or Design permission can open Settings > Library settings > Versioning settings. There, the library can require content approval, use major and minor versions, set version and draft limits, choose who sees drafts, and configure required checkout. Microsoft’s versioning instructions describe these controls.

For this workflow, enable major and minor versions and set Require content approval to Yes. Choose draft visibility so readers cannot see working text. A setting limited to approvers and the author suits a narrow review process; allowing editors to see drafts suits collaborating authors. Give employees reader access rather than edit access, and assign writing and approval to distinct people. Library permissions and draft visibility both matter: restricting who may edit a file does not itself set who may see its drafts.

Do this before moving an existing handbook into the library. When content approval is enabled, existing files become Approved; that status does not mean a person reviewed them retrospectively. The draft visibility options also include allowing all readers to see drafts, which would defeat the intended separation. Microsoft’s approval instructions make both points clear.

If the team coauthors in Word, consider checkout separately. Required checkout prevents coauthoring, so it is a poor fit when several people need to edit the document together. AutoSave can create periodic versions; it does not create a version for every keystroke. Microsoft’s explanation of versioning behavior covers those limits.

Move a change through review

For this illustrative lifecycle, the library uses 1.0 for the approved rule and 1.1 for its working replacement. A particular library may assign different numbers.

Policy state	Example text	What an employee reader sees
Approved major version 1.0	$150 cap	The current $150 policy
Working minor draft 1.1	Proposed $200 cap	The approved $150 policy, if drafts are hidden from readers
New major version pending approval	Revised $200 text with the purchase-date rule	The last approved $150 policy while approval is pending
Approved major version 2.0	$200 for purchases on or after November 1	The approved replacement, whose text still states when the new cap takes effect

The owner edits the complete replacement, resolves the October 31 question, and takes the library’s action to publish a major version for approval. With both major and minor versions in use, a major version must be published before the file can be submitted for approval. A submitted file remains Pending until it is approved or rejected. The exact command used to start that step depends on the library interface, so the important check is the resulting version and approval status, not an assumed button name. Microsoft documents the major-version and approval sequence.

To record a manual decision, the approver opens the library, selects the pending file, and selects Approve/Reject on the command bar. Choose Approved or Rejected, enter the decision comment, and select OK. This updates Approval Status. For the equipment example, a useful rejection comment names the unresolved purchase-date rule so the writer knows what to change. Microsoft’s manual approval steps

If the approver rejects the revision, the owner can correct the proposed text and submit it again; rejecting the change is not a reason to delete the whole policy file. If the approver approves it and publication completes, readers should receive the approved replacement under the configured visibility rules. The owner should check the employee-facing view after publication. For a brand-new policy with no previous approved major version, readers who cannot see drafts have no older version to fall back to and may see nothing until the first approval.

Version history helps the owner inspect or restore an earlier file version. In the library, More (…) > Version history provides those actions; restoring an older version creates a new version rather than erasing the intervening history. Microsoft’s library versioning instructions describe that behavior.

An organization could automate part of approval. Microsoft’s example flow starts when a new file is added, gets file metadata including the file’s ETag, starts an approval, and then sets the library content approval status to Approved or Rejected. The ETag is required for files and pages in that status step. The example’s new-file trigger does not establish that every later revision of an existing policy is covered. An approval comment or message alone is also not the library status update; the flow must perform that update. Microsoft’s document approval guidance supplies the example, not evidence that a particular organization has run it.

Use Notion for maintained guidance

Notion offers a lighter way to maintain the same explanation. Keep the proposed $200 wording in a draft area accessible to named editors and the approver. Keep the current $150 wording on the employee page with readers limited to viewing it. After the Finance lead actually approves the replacement, record the approval date and version in the page, then update the employee page with the purchase-date rule.

Check access at both locations. Notion permissions can inherit from a parent page, and the broadest grant wins. An editor’s access differs from a reader’s view access. An Anyone with link setting or a publicly published Notion Site is a separate sharing choice, not a substitute for the intended employee audience. Notion’s sharing and permissions guide explains those settings.

A Notion wiki page can have an owner and be marked verified until a chosen time or indefinitely, with an expiry notification. That can signal that someone has checked the page’s freshness. It does not, by itself, mean the Finance lead approved a new reimbursement rule. Notion’s wiki and verified-page guidance describes verification; verification outside wikis for standalone or database pages has separate Business or Enterprise availability. If technically enforced approval before employees can see a replacement is essential, a verification badge or an “approved” label does not supply that control.

Decide retention separately

Publishing an approved policy and retaining records of older policies are separate tasks. A SharePoint administrator needs to choose the relevant retention policy or label, scope, and period for the organization’s requirements, then use the appropriate compliance tools to retrieve retained material. There is no universal retention duration for this example.

Retention behavior also depends on the mechanism chosen. Microsoft distinguishes retention policies from standard and record labels; version limits may be ignored while a policy hold applies, while older versions under a plain retention label may still be trimmed. Versioning must be on if retaining all versions is the goal. The hidden Preservation Hold system is technical storage for retention, not a user-managed policy archive to edit or delete. Microsoft’s SharePoint retention guidance explains these differences.

Choose Notion when the main job is keeping guidance readable and assigned to an owner. Choose a configured SharePoint library when the central requirement is publishing an approved policy file while a different version is still being written or reviewed. In either case, the equipment rule needs a clear effective date and an actual decision by the named approver.

Source scope: This article describes the linked official instructions; it does not report a configured organization, a paid-tenant trial, or a tested approval workflow.