AutoSave: Nice Feature, but Office 365 Tenants Need to Keep an Eye on Network Demand

Microsoft.com

Stop Worrying About the Save Button

Last March, one of Microsoft’s posts to Blogs.office.com mentioned that an auto-save feature was coming to Word, Excel, and PowerPoint for documents stored in SharePoint Online and OneDrive for Business sites. The blog proclaimed: “With AutoSave, you can stop worrying about hitting the Save button…”

Several months later, autosave duly turned up in the click-to-run versions of Excel and PowerPoint. Now, Word boasts the feature. This made me a lot more interested in the feature because I work more in Word than any other application, so autosaving was going to affect my personal workflow. No one likes the idea of losing work just because Windows, the network, an application bug, or something else causes a crash, and the thought of having a near-guarantee that Office will preserve all changes made to files no matter what happens is compelling.

What AutoSave Does

AutoSave works by monitoring what users do inside files as they work with documents. If the user updates the content, AutoSave uploads the changes to SharePoint or One Drive for Business and merges them into the copy of the file stored in the site, with the only sign of activity being the change in the document name in the title bar (Figure 1). Here we can see that AutoSave is in the process of saving changes. When the save finishes, the title changes to inform the user that the document is “Saved to OneDrive” or “Saved to SharePoint.” Documents saved locally are noted as “saved to this PC.”

Autosave in Word
Figure 1: AutoSave controls in Word (image credit: Tony Redmond)

If you do not like the idea of AutoSave, you can disable it for an individual file by sliding the selector shown in the left-hand corner of the menu bar to Off. Although it would seem good to be able to control the feature, Microsoft has not given Office 365 tenants the ability to disable AutoSave. However, registry settings are available for PowerPoint, Word, and Excel to control whether these applications use AutoSave.

AutoSave builds on the experience Microsoft gained from document co-authoring, which allows multiple people to edit a document concurrently. Co-authoring uploads changes made by different people and merges those changes into the master copy of the document (in SharePoint). Of course, co-authoring also needs to reflect the changes made in the master to the individual copies that the contributors work on.

AutoSave Versions

Behind the scenes, once a file is saved to a SharePoint Online or OneDrive for Business site, AutoSave silently creates new versions of the file in the document library to capture changes made by the user. Depending on the versioning setting for the library, AutoSave creates a new major or minor version of the file. Apart from nomenclature, there is no technical difference between a minor and major version of a document. When all boils down, both are just an updated file.

Not every change results in the creation of a new version. Instead, AutoSave uses a version for between ten and fifteen minutes before it generates a new version and switches to it to continue saving. You might experience a slight delay when the switchover to the new version happens (just like a little hiccup), a feeling that is more pronounced if you’re not connected to a high-speed network. The exact interval between version creation depends on the volume of changes to the file. Figure 2 shows the minor versions created for the first draft of this article as viewed from a web browser.

Autosave versions
Figure 2: Minor versions for a document created in a SharePoint library by AutoSave (image credit: Tony Redmond)

Saving changes in file versions allows users to restore a specific generation of a document should the need arise. Logically, if a document is inactive and no changes happen, AutoSave does not create new versions, even for extended periods.

The user can click on the document name in the title bar to see where the document is stored and to access earlier versions. Figure 3 shows how the version (or activity) history appears in PowerPoint, in this case for a deck that I am working on for a session at the Ignite 2017 conference next month. Be sure to come by if you’re at the conference!

Autosave in PowerPoint
Figure 3: How a user can see the version history for a file (image credit: Tony Redmond)

A user can easily select an earlier version and open it to compare the content as it existed at that time. The earlier version opens in a separate window, so you can have both versions open side-by-side.

Of course, generating so many versions of a file makes it seem like you enjoy saving. One slightly amusing side-effect is that if, like me, you set up alerts to receive emailed notifications about document updates posted to SharePoint sites, you see just how many updates are logged.

AutoSave Notification
Figure 4: AutoSave activity captured in a notification from SharePoint (image credit: Tony Redmond)

The number of versions created by AutoSave do not affect the SharePoint storage allocation for the tenant as only the size of the latest version is taken into account for this calculation.

Only Office Click-to-Run

The click-to-run versions of the Office desktop applications enable AutoSave automatically for documents stored inside Office 365, if those documents are not in one of the old formats (for instance, a PowerPoint PPT file). The feature does not work for files stored on local or shared drives, so you must rely on the application’s ability to autorecover data if something goes wrong. Because it saves changes every few seconds, AutoSave is more granular and resilient than autorecover is.

The Question of Network Load

There is no doubt that AutoSave is a splendid feature from the user perspective. Unfortunately, administrators have suspicious minds and the notion of frequent document saves naturally brings the consumption of network bandwidth to mind. Not every Office 365 tenant enjoys locations where bandwidth is available in copious quantities.

Two obvious claims on bandwidth exist. First, the more frequent saving of files. Second, as AutoSave creates new versions (minor or major) for a document, OneDrive sync clients configured to synchronize the document library will download copies to workstations. You can easily see a pattern emerging by examining download events in the Office 365 audit log (Figure 5). Although some will sniff and say that synchronization will not create an obvious load, if one hundred workstations have to download a 5 MB file ten times during an editing session, it is possible that a lot of extra traffic might be generated for just one document.

Autosave OneDrive
Figure 5: The OneDrive sync client downloads a document multiple times due to AutoSave (image credit: Tony Redmond)

Some tenants will not care about the network ramifications because all their users are in well-connected locations. Others, including those who travel or work in places where the connection between their workstations and Office 365 is not so good, might consider disabling AutoSave when editing large documents.

Use with Care

AutoSave is a great example of a feature that delivers real value to users at the expense of some unforeseen overhead. I like the AutoSave feature and use it, assuming network conditions allow. Others might find that it interferes with the way that they like to work with documents. In this respect, AutoSave is a feature like the new proofing capabilities available in Word.

If you decide to use AutoSave, make sure that your network can support the new load. It might also be good to teach users about document versioning, just in case a recovery is ever necessary.

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.