Recordkeeping requires the capture and retention of event or process metadata about records; that is, data about who did what and when. This information is usually captured in audit logs or trails. In legacy EDRM systems, event metadata was captured with all other metadata about the record in the system’s database; the actual digital object was stored in a linked file share.
SharePoint Online (SPO) captures the ‘created’ and ‘modified’ event metadata in the version history for each item stored in a SharePoint site, up to the maximum number of versions (revisions) allowed.
However, the details of who viewed an item are not captured with the individual item in SPO; this information is captured in the Microsoft 365 unified audit logs. This information is surfaced in a SharePoint site only when the ‘SharePoint Viewers’ feature is activated.
However, if an item is moved from one library to another, including in a different site, the names of the people who viewed it previously seem to disappear.
This post explains what happens and what records managers might need to do if they need to capture the details of who viewed (or did other things with) an item stored in a SharePoint library.
What do we mean by view?
It is worth understanding what is meant by ‘View’ in relation to items stored in SharePoint. It includes:
- Opening the document either in a browser window or the installed application, including when the item is opened via a synced library in File Explorer. This action is captured as ‘File Accessed’ in the logs.
- Clicking on the checkbox to the left of the file and opening the information panel (the ‘i’ in a circle on the top right of the library). This opens a preview of the document. This action is captured as ‘File Previewed’ in the logs.
- Opening a page where the document can be read from a web part. This is also ‘File Previewed’.
Viewing does not include seeing a tiny unreadable icon-size image of the front page.
Enabling viewers in SPO
To see who has viewed an item stored in a SPO library, the ‘SharePoint Viewers’ feature must be activated via Site Settings > Site Actions > Manage site features.
Additionally, the option to ‘Let site owners choose to display the names of people who viewed files or pages in SharePoint’ should remained checked in the SharePoint admin center. If only ‘n views’ is displayed, this means that either the feature is disabled and/or the second option above has been unchecked.
Once the feature is activated, site members (not visitors) can hover their mouse over the document name to see the number of views and the names of people who viewed files or pages on their site, as shown in the screenshot below.

Keep an eye on the Document ID prefix and library number as these will appear in images below. As we will see, it also highlights the value of enabling Document IDs with a prefix that is the same or very similar to the site URL name.
Do viewers remain visible when items are moved?
If an item stored in a SharePoint library is moved to a different library in the same site or a different site library, using either the ‘Move to’ option or a third-party migration tool, the number of previous views and the name of those any previous viewers will seem to vanish.
In the example below, where the item was moved between libraries on the same site, the item no longer shows the number of views or the names of viewers. However, the original Document ID is retained, showing the library number of the source library on the same site. Exactly the same thing happens when items are moved to a different site.

Where did the metadata go?
The metadata about who accessed or previewed a record is captured in the unified audit logs. This is the source of the information that is seen when ‘SharePoint Viewers’ is enabled. The reason why it appears to vanish relates to the way the logs record the event; the event is still recorded, but in relation to a different library location.
Let’s look at a specific example.
The document ‘ExternalTestA.docx’ had five views in its previous location. It was moved to a different site that uses a different Document ID prefix, ‘SPADMIN’. (If it was copied it would be assigned a new Document ID with the ‘SPADMIN’ prefix). Note that the Document ID also includes a document library number. This will be useful later, as we will see.

After this document was moved, it retained all the original version history (created/modified) but appeared to have lost the viewer details.
Into the audit logs
To establish who viewed this document previously, we have to search the audit logs in the (restricted access) Compliance admin center. If you don’t have access to this center, you will need to know exactly what to ask for.
The audit log interface has the following options:
It is not possible to search for the document solely by its name despite what it says in the dialogue above. You need to be more specific and this is where the Document ID can help.
Document IDs prefixes should ideally be the same or very similar to the site URL name, which is always unique. The Document ID we see above is CORPRECORDS-518181636-49.
- The site name may be something like ‘CORPRECORDS’
- The original library has the number 518181636
- This document was the 49th added
A check of SharePoint sites shows that there is a site named that uses this Document ID prefix: https://tenantname.sharepoint.com/sites/CorporateRecords/
A check with the SharePoint Admin or site owner (for this site) indicates that the library number shown in the Document ID belongs to the generic ‘Documents’ library that has the URL name ‘Shared%20Documents’. The audit logs don’t recognise %20 so our search is for a document with the URL: https://tenantname.sharepoint.com/sites/CorporateRecords/Shared Documents/ExternalTestA.docx
The audit log search could only go back three months with an E3 licence; an E5 licence would allow a longer period. This limitation is very important to know about.
The audit logs for the last three months showed that the document was previewed in its previous site six times. It was also accessed once and then a copy captured (FileRecycled) in the original site Preservation Hold library (as the original site is subject to a retention policy) when it was moved.

The log entry includes a range of other information about the event including unique GUIDs for the organisation, SharePoint site, list (the library).
So, now it’s possible to see who viewed a record wherever it was stored – up to the maximum time period allowed by the licence. The key to seeing this information is knowing where it was stored. The Document IDs provide a very useful reference for this.
Keep in mind that the audit logs capture almost all activities from across Microsoft 365. Even on a daily basis, the volume of these logs is very large and likely not worth retaining beyond minimum periods.
Summing up and recommendations
SharePoint document libraries capture creation and modified event metadata in the version history for each item; this information is retained with the item as long as it exists, up to the maximum number of ‘versions’ allowed for each individual library (default is 500). If the item is deleted, so is the event history stored in the versioning section.
Both the created and modified and a range of other event history detail for each item is captured in the Microsoft 365 unified audit logs. This information is retained (for the time period allowed by the licence) regardless of whether an item is deleted.
Data in the unified audit logs is only retained for 3 months for an E3 licence. The logs for E5 licences are retained for 12 months; these logs (E5 only) can be subject to an audit log retention policy that will retain all or selected parts of the logs for up to 10 years. (For more details see this Microsoft Docs reference: ‘Manage audit logs retention policies‘)
Recommendation for records managers
Records managers seeking to retain the audit logs should consider arranging for the selected parts of the logs (e.g., for specific sites) to be exported on a regular (monthly) basis and then saved to those sites (in a dedicated library with restricted access and with search disabled) so that the logs will be retained as close as possible to the original records.
Feature image: Pexels