Salary Bands: Thirty Managers, Four Consultants, One Workbook

One authoritative file in a SharePoint library, permissioned by group.

• HR partners (6): Edit permission. They edit different divisions and, ideally, different tabs, to keep merge collisions rare.
• Line managers (30): Read access, but not to the whole file. Excel has no native row-level or tab-level security, so 'their own division's tab only' cannot be enforced in one shared workbook. Generate 30 filtered read-only copies from the master (a Power Query/PivotTable export per division, or a per-division view) and publish them to a read-only location. Do not hand out the master and rely on people not scrolling.
• Confidentiality: a sensitivity label that carries encryption and the correct usage rights. The label is the control; it travels with the file, is auditable, and can be revoked.

What does not protect confidentiality:

• Encrypt with Password. It is a shared secret, blocks co-authoring, cannot be revoked, and offers no audit trail. This is exactly the model that produced 11 divergent copies.
• Protect Sheet. It stops accidental formula edits and layout changes; it is trivially removable and is not a confidentiality control.
• Mark as Final. Advisory text only.

If requests for per-division views keep recurring, that is the argument for Power BI with row-level security rather than Excel.

Co-authoring requires: the file in SharePoint/OneDrive, a modern format (.xlsx/.xlsb), AutoSave on, and a client build that supports it. Any one of these defeats it.

Specific blockers to remove before rollout:

1. File-level encryption. A workbook saved with Encrypt with Password, or protected with legacy IRM/Restrict Access, cannot be co-authored in the desktop apps - each person gets a private decrypted copy, which is the version-chaos mechanism you already experienced. Use a label whose encryption setting is compatible with co-authoring instead.
2. Check-out / lock settings in the library, and any 'require checkout' policy on the document library.
3. Mixed client builds among the partners - confirm all six are on a current Microsoft 365 Apps channel, not a stale semi-annual build.
4. Editing the same cells. Even with co-authoring working, simultaneous edits to the same range produce merge prompts or lost changes. Partition by division tab.
5. External data connections and macros can prompt or block refresh for some users; keep the master free of them or document the expected prompt.

Practical guard: version history in SharePoint is your rollback. Before each weekly cycle, confirm the previous version is recoverable, so a bad merge costs minutes rather than a rebuild.

Match the artifact to the need. They need the summary sheets for six weeks - not the 14-sheet master.

• Preferred: a SharePoint sharing link scoped to the summary file, with an expiry date matching the engagement and view-only permission (or a label that enforces view-only). Expiry and revocation are the controls email attachments cannot give you.
• If they need a local copy: an export containing only the summary sheets, values-only where formulas would reveal band structure, headcount or divisional splits.
• If they only need to read and comment: a PDF removes the editing surface entirely.

Leak checks before sending:

1. Unhide everything. Hidden sheets, hidden rows/columns and very-hidden sheets travel with the file - division tabs, individual salaries and scratch calculations are the usual culprits.
2. Inspect defined names and data validation lists - they often reference ranges on sheets you thought you removed.
3. Check document properties (author, previous authors, comments) and run Document Inspector.
4. Version compatibility: the consultants run mixed Office builds. Avoid functions their builds cannot resolve, or they will see #NAME? and 'fix' the formulas themselves - the exact failure you saw last quarter.
5. Confirm the label you applied does not silently prevent them from opening the file at all; test with one consultant before sending to four.