What happens when files are moved in SharePoint?

What happens when files are moved in SharePoint?

Every SharePoint document library, including the Teams ‘Files’ tab, includes the ability to move or copy files somewhere else in the tenant. For some unknown reason, the arrow in the SharePoint library points to the right but in Teams it points to the left, and in Teams the ‘to’ is missing.

What actually happens when a file is moved from one SharePoint site to another? As we will see in this post, it is a little more complex behind the scenes than a simple ‘move’. And this complexity has potential implications for the management of records.

The move – in simple terms

To move a file, an end-user selects one or more files, clicks on the ‘Move to’ (SharePoint) or ‘Move’ (Teams Files) option, then chooses the destination library. If the destination folder has different metadata columns, the end-user will see a warning asking if this is acceptable. (To retain the metadata, the destination library must have the same columns and options).

The end-user will also be asked if the original permissions should be retained or discarded in favour of the new destination permissions.

For the end-user, the move will appear to work and the file – along with all its original versions and Document ID if enabled – will appear in the destination library. It will also retain any retention label and sensitivity label that may have been applied to the file.

What happens behind the scenes?

Although the file appears to move seamlessly from one location to another, something a little more interesting is happening.

‘File Recycled’

One of the first clues that there is something else happening is in the audit logs. At exactly the same time as the ‘Moved File’ event, we see ‘Recycled file’.

The original file has appeared in the original site’s Recycle Bin showing its original location, ‘deleted’ by the person who moved the file. Why would a file that has been ‘moved’ appear in the original site Recycle Bin? It may be because the file no longer ‘belongs’ in the site so it is deleted, which seems a bit odd and unexpected.

What is interesting about this is, as we know, files in the Recycle Bin can be restored. But before we look at that point, if a file was deleted AND the site is covered by a ‘back end’ Retention Policy, it will also appear in the Preservation Hold library with all the versions, as can be seen in this screenshot.

The version history details match those in the destination library:

So, even though the file was ‘moved’, with all its versions (and original Document ID as can be seen below), a deleted copy remains in the source site.

What happens if the deleted original is restored?

As noted above, the original file appears in the Recycle Bin (for up to 93 days) as well as the Preservation Hold library.

It is not possible to restore an item from the Preservation Hold library, but it is possible to restore it from the Recycle Bin. If it is restored, the file is returned ‘back’ where it was originally stored – with the same ID and the same metadata.

This means we could have two identical records, with the same version history and the same Document ID, in two different sites. These are not in any way cross-linked.

It is unlikely this will happen frequently, but it is possible; the source site version in the Recycle Bin provides no clues that it may have been moved to a different location.

Audit log history

As noted above, the audit logs record the ‘move to’ event with details of the source and destination. There is no other reference to the ‘creation’ (or ‘receipt’) of the file in the destination library. However, the audit logs do provide, for the period permitted by the licence* or retention policy, details of all other events relating to the file in its original source or destination location. This includes if the file is restored from the Recycle Bin. Keep in mind that documents will similar names may also be returned.

*E3 licences = 3 months, E5 licences = 12 months

Implications for records management

The primary implication for records management is about the authoritativeness of a record. If a record is moved to a different location that should be the authoritative version, along with its full version history.

However, Microsoft 365 ‘deletes’ the file (record) from the original location from where it can be restored. If the site has a ‘back-end’ retention policy, all the versions of the ‘deleted’ file will be captured in the Preservation Hold library for the life of the retention period.

Generally speaking, the chances of a moved file being restored from the Recycle Bin is not high but it is not impossible. It would be not much different from a copy of a paper document existing in more than one location.

Feature image – Photo by Mikhail Nilov: https://www.pexels.com/photo/an-aerial-photography-of-moving-cars-on-a-roundabout-6943272/

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s