Policy version control when changes happen in Slack
Policy workarounds get agreed in Slack threads while the doc in Google Drive never changes. How to spot the multi-version policy trap and audit for it.
The short answer
Version control for company policies has to cover more than the document. Google Drive's version history only records edits to one file, so it misses the copies, the PDF exports and, most of all, the workarounds agreed in Slack threads that were never written into the policy at all. Keep one canonical file per policy with a stable link, a header naming its owner and effective date, and a changelog that records every exception with an end date. Then audit regularly: find duplicate and exported copies in Drive, search Slack and email for decisions about each policy, compare the rules they state, and send each conflict to the policy owner. Ingesto runs that audit continuously: it reads Drive, Slack, Teams and email, and flags every place a policy disagrees with a newer decision to its owner.
The multi-version policy trap
In March, the company moves to a new corporate card provider, and the rollout takes a while. Someone asks in #finance-help what to do about meals on a trip before their card arrives. The finance lead replies: for now, expense up to $75 a day with no receipt needed, until the new cards are out. Twelve people react with a thumbs up.
The cards arrive in May. Nobody says the workaround is over. In September, one manager is still approving $75 no-receipt meal claims because that's what the thread says. Another rejects them because the Travel & Expense Policy in Drive says $50 a day with receipts. The HR handbook, exported as a PDF last year, says $40. And there are two copies of the expense policy in Drive: "Travel & Expense Policy v4" and "Travel & Expense Policy v4 FINAL (1)", which differ on who approves international travel.
That's four versions of one policy, and none of them is obviously the one people should follow. No one did anything wrong. A temporary answer was given in the right place at the right time, and it outlived its reason.
Why Drive's version history doesn't solve it
Google Docs keeps a version history, you can name versions, and for uploaded files like PDFs, Drive lets you upload a new version in place so the link stays the same. These are good features and you should use them. But they all track changes to one file, and in the example the conflict isn't inside any one file.
- The Slack workaround never touched the document, so there's no version of it to find.
- "v4 FINAL (1)" is a separate file with its own history, and neither file knows the other exists.
- The handbook PDF is a snapshot. Editing the source doc doesn't update the copy people actually open.
- Nothing in version history tells you the $75 exception was meant to end in May.
Real policy version control means tracking the policy, not the file: every place its rules are stated, including the conversations where they were changed.
Five places a policy's versions hide
| Where it hides | Example | Why it survives |
|---|---|---|
| The thread workaround | "For now, $75 a day, no receipts" | No end date, and no one owns ending it |
| The fork | "v4 FINAL (1)" in a team folder | Made to adapt the policy, then forgotten |
| The export | Handbook PDF, onboarding deck, LMS course | A snapshot that never hears about edits |
| The pin | A pinned Slack message quoting last year's limit | Pinned once, never unpinned |
| The memory | The manager who approves what they remember | The hardest to find, and it follows the loudest version |
Rules for keeping one version of each policy
Before you can audit, you need a clear answer to "which one counts?" These rules give you that, and they make the audit much shorter the second time.
- One canonical file per policy, with a stable link. Replace it in place (edit the Doc, or use Drive's option to upload a new version of a PDF) instead of creating "v5" or "FINAL". Everything else links to it.
- A header on every policy with the owner (by role), the effective date, the last review date and a version number, so a reader can tell at a glance what they're looking at.
- A changelog at the bottom: the date, what changed, who approved it, and a link to where it was announced. When a change starts in a Slack thread, the thread goes in the changelog.
- Temporary exceptions are written into the policy, not only the thread, with a start date, an end date and who they apply to. "Until the new cards arrive" isn't an end date. "Until May 31" is.
- Exports carry their date and a line saying "check the current version at" followed by the canonical link. Where you can, link to the policy instead of exporting it.
The audit protocol
Run this once for your ten most-used policies (expenses, leave, remote work, travel, security and so on), then repeat it monthly, or keep it running continuously.
1. Inventory every copy
Search Drive for each policy's title and its key terms. Look specifically for the signs of a fork: "Copy of", "v2", "FINAL", "(1)", "old", and PDFs with the same name. Check where the policy is embedded too: handbooks, onboarding decks, training courses. List every copy with its owner and last modified date.
2. Pull the decisions from chat and email
Search the channels where people ask HR, finance and ops questions for each policy's terms alongside decision words: "for now", "until", "going forward", "exception", "approved", "from now on". Slack's in:, from: and after: modifiers narrow it to the right channel, person and period. Do the same in the shared inboxes where exceptions get approved.
3. Compare the rules, not the wording
For each policy, write down the concrete rules each source states: the amounts, time limits, approvers, eligibility and dates. Differences in wording don't matter. Differences in rules do. $50 with receipts, $75 without and $40 are three rules.
4. Classify each finding
Most findings fall into one of four kinds, and each has a standard fix:
- Conflict: two current sources state different rules. The owner decides which is right.
- Expired exception: a temporary rule with no end date, or one that's past it. The owner ends it or makes it the policy.
- Duplicate: a fork or copy of the canonical file. Merge anything it got right, then archive it.
- Stale export: a snapshot of an older version. Replace it with a link or a fresh, dated export.
5. Route it to the owner with the evidence
Each finding goes to the policy's owner with every conflicting source quoted side by side, with dates and links. An owner can settle a conflict in minutes when the evidence is in front of them, and will put it off for weeks if they have to go looking.
6. Close the loop
Update the canonical file and its changelog. Move forks into an Archive folder and rename them "ARCHIVED, superseded by" with the link. Reply in the original Slack thread with the outcome, so the people who saw the workaround see that it's over. Unpin anything that quotes the old rule.
Where Ingesto fitsIngesto runs the audit continuously
Steps 1 to 5 are the part that takes days by hand. Ingesto does them all the time. It reads your policies where they already live, in Google Drive, Notion, Word files and PDFs, alongside the Slack, Microsoft Teams, Gmail and Outlook conversations where exceptions get agreed, and compares the rules they state.
When the finance lead posts the $75 workaround, Ingesto files it against the expense policy. When it contradicts the policy in Drive, the policy owner sees both side by side, with the thread linked, and can make it a dated exception or correct it in one go.
- Finds duplicate and forked copies of the same policy across Drive, Notion and PDFs.
- Picks up policy decisions from Slack, Teams, email, and Zoom or Google Meet calls.
- Flags every conflict to the policy owner, with each version quoted and dated.
- Gives employees one place to ask what the policy is today, with its source.
What changes when the audit runs continuously
Done by hand, this audit takes a few days for ten policies, and by the time you've finished, someone has agreed a new workaround in a thread. A monthly audit catches a conflict up to a month after it starts. Continuous audit catches it the day the thread is posted, while the person who made the decision still remembers why, and before a second manager starts approving by it.
