Send To One of our friends in Europe, Vincent, posted these great questions to the Microsoft Developers Network and then alerted me to them through a comment on my ‘About Me‘ page:

“We’re implementing a SharePoint solution wherein we send a document (or document set), when final, via the send to connection to the drop off library in a record center. We don’t use in place records management. However, when using this out-of-the-box functionality, the document in the drop off library gets a new Created On and Created By stamp and the versioning of the document is skimmed, for no apparent reason? 

Probably we are doing something not by the book. Retaining these two fields and the versioning are, for RM purposes, essential elements for securing the integrity of the document (sets) during the entire Document Life Cycle. And the only way to get a SharePoint item (out-of-the-box) in the Drop-Off-Library is the send to connection.  

So:

1. How can we retain the Created By and Created On metadata through the send to connection?

2. How can we retain the previous versions of a document whilst using the send to connection?”

I thought these were such good questions and so relevant to what we discuss here that I would post this separate article as a response.  Unfortunately, I think Vincent is looking for a technical solution and I am going to give him a records management answer instead.  Hopefully, it will be good enough. 

I noticed the issue with the modified ‘Created By’ and ‘Created On’ changing soon after I started using SharePoint 2010 and the Content Organizer feature.  I’ve spoken to a couple of my SharePoint developer friends and they tell me there is no easy way to keep these values from changing after the record has passed through the Drop Off Library.  It can be done, I am told, it just wouldn’t be easy – or cheap.  (I seem to get this response pretty often for some reason.)  So I asked myself, ‘Don, how important is it from a records management perspective that these fields remain constant throughout the declaration process?’  Turns out, not so much. 

Let’s take the ‘Created On’ value first.  There really shouldn’t be any value to having a record property that indicates when the original, transitory document was first created.  That information really isn’t relevant to managing the document as a record.  What is relevant is knowing the day the document was declared a record because many (though certainly not all) retention periods start on that day. 

Think of the old paper records world.  Back then a document could float around an organization for weeks or even months – in a transitory state – before it is sent to the basement records repository.  If the record is subject to a time-based retention period, the day that paper document arrives at the records repository is the first day of its retention period.  It would be the same with the electronic version arriving in the SharePoint Records Center.

So my advice here is to look at the retention requirements of the record.  If they are time-based, you probably want the Created On date to be the date the record was declared.  If the retention is case-based, the Created On date has very little value.

The ‘Created By’ property is a little different.  It may make sense to want to know who originally created a record.  And if you use the Drop Off Library this value will change.  However, before you invest a lot of resources in making sure the Created By value doesn’t change, I would encourage you to consider creating an organization defined field (Originally Created By?) as part of your enterprise record Content Type that would remain the same throughout the record’s lifecycle.  I’m willing to bet that workaround would provide sufficient information to effectively manage the record through its final disposition and save you a lot of time and money in the process.

As for losing previous versions of a document when it passes through the Drop Off Library, I would argue that this is exactly how you would want the process to behave.   There are very few reasons to want your record to include previous versions.  In fact, maintaining those old versions can only cause your organization pain if it is ever part of a response to a discovery order. 

Think again back to the paper records world.  Was there ever a need to maintain previous draft versions of your paper records?  Probably not.  And the same standard should apply here.  Besides, by default, the ‘Send To’ function does not delete the original document (or its history).  If you want to maintain previous versions of the document, they can stay in the collaborative space as long as you want them to.