Budget (Conflicted Copy 2)
Lee's team of five shares one cloud folder called 'Client Work'. It was created from Lee's personal account, which is registered to his old university email address; the university address will stop working when Lee leaves the company in three weeks, and the account will then be closed. Everyone in the team has edit rights. On Tuesday two people edited the same budget spreadsheet; the service kept both versions as 'budget (Lee's conflicted copy)' and 'budget (conflicted copy 2)'. Afterwards a client's contact details were overwritten with an old address and a proposal went out quoting the wrong figure. The team also receives an email for every file change, roughly 60 a day, and has started ignoring them.
1. There are three problems here: account ownership, permissions and notifications. In what order should they be fixed, and why that order?
Read the worked answer
1. Ownership first. 2. Permissions second. 3. Notifications third.
- Ownership is first because it is the only irreversible deadline. In three weeks the account is closed. When that happens the folder may be deleted or become inaccessible, along with its version history, and recovering it requires proving ownership with an email address that will no longer work. Every other problem stays fixable after the deadline; this one does not.
- Permissions come second because they are causing active damage right now. A wrong figure has already gone to a client. Moving the folder to a company-owned account and then restricting edit rights is one operation in practice, and it should happen the same day.
- Notifications come last because they are a symptom, not a cause. Sixty alerts a day is what happens when everyone can edit and nobody knows what to watch. Once permissions are set, the team can choose targeted alerts on the few files that matter instead of all of them.
2. Lee proposes telling the team to 'be more careful when saving'. Explain why this will not work, and describe a structure that would.
Read the worked answer
Why the advice fails: the existence of two conflicted copies is evidence that two people opened the file believing they had the current version. Neither was careless; the tool gave them no signal that another person was editing. A warning to be careful asks people to compensate for a defect in the setup using memory and guesswork, and it will fail the first busy Tuesday.
A structure that works:
- Move the folder into an account the organisation owns, and transfer ownership formally so the sharing links and history survive.
- Change the default to 'can view'. Grant edit rights only to the people who genuinely need to change files - probably two of the five rather than all five.
- For the budget specifically, nominate one editor at a time. Anyone else comments or suggests rather than edits. State this explicitly rather than assuming it.
- Use the service's real-time co-authoring where it exists. Genuine simultaneous editing in one live document removes the conflict entirely, whereas a sync-and-merge model on a file attachment cannot.
3. To repair the client's contact details and the proposal figure, is it enough to open the most recently modified copy? What is the reliable method?
Read the worked answer
No. Recency is not the same as correctness, and this is exactly where teams make things worse.
- A conflicted copy's timestamp records when it was saved in that state, not when its contents were last confirmed as accurate. The newest file may be the one containing the old address.
- The reliable source is the version history of the master file, which records what the document said at each point in time. The team should find the version from just before the overwrite, confirm which edits made in the same period were legitimate, and restore selectively.
- Then verify against the outside world rather than against the file: ring the client to confirm the current address, and re-check the proposal figure against the source data.
- Finally, consolidate: publish one master as the only editable version, mark the conflicted copies read-only or delete them after archiving, and tell the team which file is now authoritative. Leaving three plausible-looking budgets in a shared folder guarantees the same incident again.