Having read the standard documentation on both the Document Centre and Records Centre for SP I wanted to know your first hand experience with any or both. I would not want this question to be marked 'too generic' so I am giving some specifics: in a mid-size organization with still a primitive view of SharePoint (no metadata, almost no idea of document life-cycle, no governance, no previous training, no previous user adoption strategy) we have been advised by an external agency to impose both the Document Centre and the Records Centre (the first being the recipient of all documents sent from the various team sites and the second being the recipient of the 'records' of the same documents after a period of time).

Has anybody see this type of combo? does it even make sense from a logical point of view? especially in a beginners' situation?

I personally never saw a proper implementation of the document centre or the records centre that was satisfying for the users and the company goals. I have also heard of complaints of the look and feel of the document centre that is obviously different from team sites and publishing sites. This can be detrimental to user adoption success. A lot of people might simply stop sending the document to the document centre.

What has been your experience?


For the record: I can share experience from small & mid size 2010 / 2013 farm implementations & O365 tenants only, but someone has to start :)

Document Center is collaboration place which can contain libraries where all possible things that you may need for a work with the document are tuned on by default. Versioning is enabled with 10 or more tracked versions of each document, (sometimes annoying) check-in/check-out feature is turned on, workflows can control document life cycles, document ID can be used, etc. It is designed for a use cases where large-scale document management is needed.

Based on my experience, many companies use DC on ShP 2010/2013 like intelligent file share with folder or metadata driven navigation. For sensitive large files accessible four times per year like financial reports or on the other hand for something well watched, but unchanged for a year or so, shared on public, like company policy guides. Some companies small enough to not care about IRM, file plan, retention policies and such kind of things in general, use it like hidden sub-site inside each SC for archive purposes. Data are moved there for some amount of time, before somebody shift them to backup or tape and delete forever. Personally, I do not know any customer who uses DC in SharePoint online, not for now.

Records Center is long-term archive where data are locked, due to fact that declared records by the definition cannot be modified by human or system. (Metadata can be stored and updated separately like XML files, without modifying the stored record itself). Versioning, auditing, metadata management, eDiscovery, and customisable record routing and holds that prevent deletion are enabled there. Document destruction is configured through the retention policies. Some features used there can be turned on separately somewhere else (e.g. Content Organizer, that can automatically route incoming to their proper location, based on their record type), but due the fact that document parsing functions are turned off for that site by default (property bag values promotion / demotion), it operates much faster for the file operations like upload, delete or “sent to” than ordinary site templates. It is designed like that by purpose, to be able to hold large number of data. Much more than on any other sites at all.

Based on my experience, RC was rarely used in 2010, comes better in 2013, will be much better with 2016, but still I can’t remember customer who used both in combo for one use case (e.g. store financial reports in DC for 5 years and then put them into RC remain locked), mostly because of storage ( = money, ShP/SQL often uses fast and expensive disk subsystem and customers don't want to store "dead" data there for 5 years or so). If the customer has legal department or care about legal cases worldwide (US and Europe has different set of standards per one type of document), usually have one or two RC sites in place, with few policies and content types (and what was configured at the beginning often remains unchanged for years). On the other hand, unlike DC, Record Center is used by customers with SharePoint online.

I can imagine some use cases where both are involved, but in your case little steps heading to main goal (to get all data classified, maintained and stored) are needed. One DC site template for all kind of documents sent from various portal places without proper description can be really a bad idea (not mentioning stored them like that for years). For the RC, you have to have clear classification strategy already in place, because files can be moved based on rules - type or metadata only. You need to know what type of file for which amount of time you need to store there (who is the owner if audit comes, what type of file it is, etc.) and than after configure stages, rules or moves. Usually if you can't see the additional value behind it, if it is not time saver or if it is too complicated to use, you will stop using it after some time. It happens everywhere.

  • Very useful (I forgot to mention that my scenario is on SPO). However, 2 more small questions: 1) since you can apply data retention on everything, what is the selling point of data retention applied to the document centre? Data retention implementation is priority so if you correctly mentioned that it happens everywhere that eventually you stop using it and you have applied data retention policies there, you are in trouble since you did not apply it by content type on sites collection... – susan Jul 31 '17 at 7:49
  • 2) You said you don't know of the DC used in SPO. Given the SPO situation and the fact that beginners are heavily invested in having their files in their department site collection, wouldn't it be seen as a duplication of those other locations just with a worse look and feel? People generally do not like having their files visible during drafting so I would see the DC as a repository of completed files and not work in progress files. File gets worked in your team site and then gets sent to the DC, does it sound reasonable? – susan Jul 31 '17 at 7:55
  • First, let's me imagine like consultant - my job responsibilities contain customer implementations, trainings or installations done in a different countries or for different customers all the time. When work is finished, user trained & guides handover, I am leaving the company for a next job. The sad truth is, what we set during the project is way different after year we come back. I can create semi-automatic portal pages based on search driven content, setup RM features, things without a custom code but bit advanced and there is often nobody to maintain them after. – Molik Jul 31 '17 at 9:09
  • Many customers still underestimate the need of content admin in place (trained power-user(s) that will keep an eye on the already created content). Once that site is created it is “preserved“ and wait for our return. Already created processes works, but nobody add new file types, modify the rules or check the already moved content until legal hold is placed or issue of disappeared file is raised. – Molik Jul 31 '17 at 9:09
  • You cannot apply retention rules to everything, that was my point. Or technically, you can of course, but one day you can figure out that your files are gone for no reason. Even non-important things like e.g. blog images (can be important too, I just used them like example here). Also, do you want to hold non-work related content like lunch menu list in Microsoft Word for a 5 years? You should identify what type of content you want to archive / put on hold first, create your own content types for that reason and those used for retention. – Molik Jul 31 '17 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.