Policies
Most companies have policies somewhere: a PDF from three years ago, a page in a wiki nobody opens, an email everyone was told to keep. Nobody’s sure which version is current, and when someone says “I never saw that”, there’s no way to answer. Policies is where they live instead: written in markdown, published as a numbered version, reviewed on a schedule you set, and, when it matters, acknowledged by the people it applies to with a date against their name.
- Who can use it: managers write, publish and see who’s signed. Supervisors, employees and HR read the policies that apply to them and acknowledge when asked.
- Where: Sidebar → Policies.
- Default: off. Turn it on at Settings → Modules.
Every policy gets a reference number (POL-DDMMMYY-XXXX).
When you publish a policy, mizuiro freezes the text as v1. Editing afterwards changes a working copy that only you see; people keep reading v1 until you publish again, which freezes v2. Every acknowledgement records which version was signed, so a rewrite never silently changes what someone agreed to. Old versions stay readable, clearly marked as history.
- Sidebar → Policies → New policy.
- Give it a title and write the policy in markdown. Headings (
##), bullets, numbered steps, bold, and links ([text](https://...)) all work. There are no file attachments; link to anything that lives elsewhere. - Choose who it applies to: everyone, or specific teams. A team policy covers the people on those teams and the supervisors who run them. People who have left are never asked.
- Decide whether staff must read and acknowledge it, and optionally how many days they have.
- Optionally set review every N years and an in effect from date.
- Save draft. Drafts are yours alone.
- On the policy page, click Publish. It becomes v1 and appears for everyone it applies to.
To change a published policy: Edit, save, then Publish changes. You’ll be asked what changed and, if the policy needs acknowledgement, whether it’s a material change (everyone signs again) or a minor edit (typos, wording; existing signatures stand).
If you set “review every N years”, the next review date is counted from the last publish or the last review. Policies due within 60 days appear at the top of the Policies page and in the Policies Due for Review widget, and you get one email 30 days out (once you’ve turned that notification on).
Most reviews end with “still fine as written”. For that, click Mark as reviewed, no changes: it resets the date without creating a version. If it does need updating, edit and publish; that resets the date too.
When a policy requires it, everyone it applies to sees a banner ("Expense claims needs your acknowledgement") until they open the policy, tick I’ve read and understood this, and click Acknowledge. That’s recorded with the version and the date.
On your side, Who’s acknowledged (from the policy page) shows two lists: outstanding and signed. From there you can:
- Send a reminder to everyone still outstanding (email, if that notification is on).
- Record for them: for someone who signed a printed copy, or who doesn’t sign in to mizuiro at all. Your name goes on the record as having recorded it, with your note.
- Export CSV (one row per person with their status) or Export PDF (the policy text with the acknowledgement list appended), for the auditor who asks.
New hires inherit whatever’s outstanding: a policy they haven’t signed shows in their banner from their first sign-in. The Policies tab on each person’s profile shows what they’ve acknowledged and when.
Retire this policy takes it out of everyone’s list without deleting anything: the versions and acknowledgements are kept, and you can reinstate it later.
Two notifications, both off until you turn them on at Settings → Notifications:
- When a policy needs someone’s acknowledgement: to each person it applies to when you publish a version that needs signing, and again when you send a reminder.
- When a policy is due for review: to you, 30 days before, once per cycle.
| Widget | Size | Who | What it shows |
|---|---|---|---|
| Policy Acknowledgements | 1x1 | Everyone | Managers: signatures still owed across all policies. Everyone else: policies they still need to sign. |
| Policies Due for Review | 2x1 | Managers | Published policies due for review within 60 days, overdue ones first. |
Can supervisors write policies?
No. Policies are the company’s voice, so writing and publishing stay with managers. Supervisors read and acknowledge like everyone else.
Does a minor edit really not ask anyone again?
Right. If you pick “minor edit” when publishing, everyone who signed the previous version stays signed. Use it for typos and wording; pick “material change” whenever the substance moves. You decide each time.
What happens to acknowledgements when someone leaves?
They stay with the policy’s history for as long as the person’s record exists. Policies and acknowledgements aren’t part of the retention purge; they’re the compliance record.
Can I attach the PDF version of our handbook?
Not as a file. Paste the text in (it’s markdown, so headings and lists carry over cleanly) or link to where the file lives. Text in mizuiro is what makes versions and acknowledgements possible; a file attachment would be a black box.
NoteHow to read this: ✓ can see it, ✗ can’t, ○ depends on a setting or condition (explained under the table). As a manager, you always see everything in your company.
| What | You (manager) | Supervisor | Employee | HR |
|---|---|---|---|---|
| Write, publish, retire | ✓ | ✗ | ✗ | ✗ |
| Read a published policy | ✓ | ○ | ○ | ○ |
| Drafts and unpublished changes | ✓ | ✗ | ✗ | ✗ |
| Acknowledge | ✗ | ○ | ○ | ○ |
| Who’s acknowledged, reminders, exports | ✓ | ✗ | ✗ | ✗ |
| A person’s Policies tab on their profile | ✓ | ○ | ✗ | ✓ |
- ○ Read / acknowledge: only the policies that apply to them (everyone, or their team; for a supervisor, that includes the teams they run). Managers aren’t asked to acknowledge; they publish. Observers read everything and can export it, but don’t publish or record.
- ○ Supervisor, profile tab: for people on their teams (everyone in shared scope).