Deleting a document managed by RecordPoint:
Deletion of a file in a SharePoint Online environment using 365Connect or the Records365 v1 service consists of two processes:
- Delete the item and move it into the Recycle Bin (RequestType - ActiveDeleteSubmit)
- Download and submit the binary into RecordPoint (RequestType - ActiveDownload)
These two RequestTypes will enter the middle-tier queue as an item goes through the deletion process as outlined below.
Before a deleted file is moved into the Recycle Bin , RecordPoint intervenes by pausing the deletion and first downloading the binary into RecordPoint . During this process, it also captures some metadata information of the document (the actual user's name that deleted the file) which will be available in its Audit trails in RecordPoint. After the binary has been downloaded, the process of moving this file into the Recycle Bin continues but now will be performed by RecordPoint , so when SharePoint captures this information it displays the "Modified By" field as "SharePoint App" (which in this case, refers to RecordPoint). The reasoning behind this behavior is to avoid timeouts and race conditions when downloading large files.
To improve the end user experience in SharePoint Online, when a user deletes a document/list item or folder/document set/document library/list:
- The item is immediately removed from the user's view by deleting all permissions from the item, but members with full access will still be able to view the item until the RecordPoint deletion/download process has completed. This occurs during step  in the process above.
- An error message is no longer displayed when an item is deleted
Once the download into RecordPoint has completed, the file is moved into the Admin recycle bin and removed from the library/list - the amount of time it takes for this step to complete can vary depending on multiple factors such as middle-tier queue load and file size. Because the deletion is carried out by RecordPoint, the Deleted By field will contain "SharePoint App" as its value. Therefore, the deleted file's name will have "_RPDelete_[username]" appended to it in order to reflect which user performed the deletion. One expected side-effect of this is that the deleted document will not appear in the user's recycle bin - if it needs to be restored, this needs to be done from the Admin recycle bin by an administrator.
Restoring a RecordPoint-managed document from the Admin recycle bin:
There are two things to be aware of when restoring a document that was managed by RecordPoint:
- The permissions for the item will remain stripped as carried out by the deletion process. Non-admin users won't have access to the item after the restoration.
- Solution: go to the permissions page for that item and click "Delete Unique Permissions" which will then inherit permissions from the item's parent. This can be done in bulk via the SharePoint Online CSOM if needed. If further unique permissions are required, then these will need to be manually added.
- The item will retain the "_RPDelete_[username]" addition in its name. Simply rename the item as required after the restoration.
- It's recommended to ensure that a document is not flagged for move* before deleting it. An item that is deleted while flagged for move will not be processed or captured by RecordPoint (i.e. the delete process explained above will be ignored) - this is due to how SharePoint Online handles moves, as from a technical standpoint it's currently not possible to differentiate between a move and a delete.
- Solution: before the item is deleted, simply unflag** it. If the delete already occurred before unflagging, then restore the item from the recycle bin (in this case, admin or user bin will work) and perform the delete again. The flag for move will no longer apply after the restore, so the following delete will then be registered by RecordPoint.