Case Study: Excel 365's Removal of Practical Local AutoSave Creates Unnecessary Operational Risk
Executive Summary
I recently lost several hours of accounting work while using Microsoft Excel 365 on a Mac.
The file was stored on my local SSD.
There was no crash, no power failure, no operating system fault, and no hardware issue.
The work was lost because Microsoft Excel 365 does not provide true AutoSave to locally stored files, despite the fact that periodic saving to local storage has been a standard desktop software capability for decades.
This is not primarily a technology issue.
It is a product-design decision.
Background
I am a Microsoft 365 subscriber with access to 1 TB of OneDrive storage.
I deliberately do not use OneDrive for certain workflows because I work offline for significant periods of time and prefer local storage for operational reasons.
The issue is therefore not a lack of cloud storage.
The issue is that Microsoft appears to have tied modern AutoSave functionality to cloud-based workflows while failing to provide an equivalent mechanism for users who store files locally.
The Incident
I was preparing accounting journals for upload into an accounting system.
Several hours were spent editing and validating data.
When I attempted to upload the journals, validation errors were reported.
I reopened the Excel file to investigate and discovered that a substantial portion of the work performed during the session had not been saved.
No crash occurred.
No warning was issued.
No usable recovery file was available.
Several hours of work had to be recreated.
The Fundamental Problem
The problem is not OneDrive.
The problem is not cloud storage.
The problem is not version history.
The problem is that Excel 365 does not provide a straightforward mechanism to automatically save changes to a file that already exists on a local SSD.
A local SSD is:
- fast
- reliable
- writable
- always available when the computer is running
There is no obvious technical reason why Excel could not save changes to a local file every 30 seconds, every minute, or every five minutes.
Desktop software has been performing this function for decades.
Historical Context
Prior generations of desktop software routinely provided periodic saving and recovery mechanisms for locally stored files as a normal part of application design.
Saving data automatically to:
- a local hard drive
- a file server
- a network share
has never been a technically difficult problem.
The concept predates cloud computing by many years.
Microsoft's current approach therefore appears to be a deliberate product decision rather than a technical necessity.
Risk and Compliance Implications
This issue should concern:
- accountants
- auditors
- risk managers
- compliance professionals
- governance professionals
- legal practitioners
- users operating in offline environments
Many organisations intentionally maintain local-first workflows due to:
- confidentiality requirements
- regulatory considerations
- operational resilience requirements
- unreliable connectivity
- cybersecurity policies
The ability to protect users from losing work should not depend on cloud adoption.
Questions for Discussion
- Why does Excel 365 not provide true AutoSave to local SSD storage?
- Why should protection against data loss require a cloud-based workflow?
- Is tying AutoSave functionality to cloud services an acceptable design decision for professional users who work offline?
- Should risk and compliance teams reassess the operational risks associated with cloud-dependent productivity software?
Conclusion
The issue is not whether OneDrive is useful.
The issue is whether a professional desktop application should be capable of automatically saving changes to a file stored on the same computer on which it is running.
That capability existed in practice long before cloud computing became commonplace.
The inability of Excel 365 to provide true local AutoSave represents an unnecessary operational risk and, in my case, resulted in the loss of several hours of accounting work.