Legal Manager holds the documents your organisation publishes and stands behind: terms of service, privacy policy, acceptable use, anything else somebody might one day have to prove the wording of.
It is the most quietly valuable surface in Web, and the one most often left as placeholder text.
Why these are not just pages
Because the question is never "what do the terms say". It is "what did the terms say in March, when this customer signed up".
An ordinary page cannot answer that. This can.
Versions
Every document keeps a numbered history.
A version number, suggested automatically as the next increment from the last one.
A changelog, which is where you say what changed and why.
A published date, recorded when it went live.
That is the whole mechanism, and it is what turns a page into evidence. A customer disputing a clause, a regulator asking when a policy took effect, an auditor checking you did what you said: all three are answered from the history rather than from somebody's memory.
Write the changelog properly
The field people leave blank, and the one that makes the rest worth having.
Say what changed, not that something did. "Updated" tells a future reader nothing. "Added clause 7.3 covering data retention after account closure" tells them everything.
Say why, when there is a why. A change made because the law changed reads very differently in two years from one made because somebody preferred the wording.
Thirty seconds now, and it is the difference between a history and a list of dates.
What belongs here and what does not
Here: anything you publish, stand behind, and might need to prove the wording of on a given date. Terms, privacy, acceptable use, cookie policy, data processing terms, refund policy, service levels.
Not here: internal policies your staff acknowledge. Those belong with policies and acknowledgements in People, where there is a record of who accepted what.
The distinction is audience. This is what the public sees.
Draft, published, archived
Three states, and each means something specific.
Draft is being worked on and is not public. Legal wording goes through review, and review takes days.
Published is live and is what a visitor sees.
Archived is a document you no longer publish but have not thrown away. That distinction matters: a superseded policy is exactly the thing you need to produce when somebody asks what applied at the time.
Never delete a published legal document. Archive it. Deleting it destroys the only record of what your customers agreed to.
Keep a copy outside the product
Not because anything here is fragile, but because legal documents are the one thing you may need during an incident that takes the rest offline.
The effective date
Separate from when you published it, and worth using.
A policy published today may take effect in thirty days, which is common practice and sometimes required. Recording both means you can answer what applied when, rather than assuming publication and effect are the same moment.
Getting it reviewed
Somebody other than the editor approves it. The most common failure here is not a bad clause, it is a change that nobody outside the person making it ever read.
Keep it in draft while it is being reviewed. The temptation to publish and fix is understandable and wrong: a legal document is published the moment it is published, whatever you intended.
Who can edit these
Narrower than most permissions.
The ability to edit a legal document is the ability to change what your organisation has committed to, and it should sit with very few people. Give it to whoever is accountable for the wording, not to whoever maintains the website.
Two people, minimum. One is a single point of failure on documents you may need to update urgently.
What to publish first
Privacy policy and terms of service. Every visitor eventually looks for both, and in most jurisdictions you are required to have at least one of them.
Then whatever your industry demands. Acceptable use, cookie policy, data processing terms, refund policy.
Placeholder text is worse than nothing. A privacy policy that is obviously a template with a company name substituted in is read as a signal about how seriously you take the rest.
Slugs and links
A legal document has a path like anything else, and it is quoted in contracts, in emails and in other people's records.
Set it once and never change it. /privacy and /terms are the conventional choices and there is no reason to be inventive. A path change on a legal document breaks references in agreements that may still be in force.
Superseding, not overwriting
When a policy changes, the old one does not stop having existed.
Publish a new version rather than editing the live text. Editing in place leaves you with a document that says one thing and no record that it ever said another, which is precisely the situation versioning exists to prevent.
The changelog and the version number are what make the difference between "our privacy policy" and "our privacy policy as it stood on 14 March", and only the second is any use in a dispute.
Two habits
Review annually, on a date. Not "when something changes", because the things that should trigger a change are exactly the things nobody notices.
Tell people when it matters. A material change to terms usually needs to be communicated rather than quietly published. The version history tells you what was material; it does not send the email.
What it will not do
It will not write them. These are legal documents and you should have somebody qualified draft them. What this gives you is somewhere to hold them properly.
It will not tell you what you are required to publish. That is jurisdiction-specific and changes.
It will not collect acceptance. Recording that a specific person agreed to a specific version is a signature question, and that is Documents.
Did this answer your question?
No, ask a person