Records Center Q&A

Thanks to everyone who posted questions about the Records Center or sent them in via the “contact” form. (It’s great to receive such detailed questions – it shows how many people are really interested in the records management capabilities of the next release!)

So before moving on to our next topic (hold orders in the Records Center), this post will try to answer most of the questions we’ve received so far.

What if I don’t want to have separate collaboration and records center sites… can my end-users work directly against the records center?

As we’ve said in various posts to date, we believe that the model of separate collaboration sites vs. record sites provides a significant usability/ adoptability advantage for most organizations implementing a records management program. That said certain organizations may want to institute a program where their end-users are required to (a) directly understand their company’s file plan, (b) file records directly into the file plan, and (c) treat all of the content they work on as records.

Fortunately, the Records Center site in the 2007 release can be configured to support this model as well – thanks to the improvements made in the security model of Windows SharePoint Services. In the 2007 release, users can be granted very specific/restricted rights to objects in the Records Center site – for example, the ability to add new records, but not the ability to modify any existing record (and even without the ability to view existing records if desired). And these rights can be granted selectively across individual document libraries within the Records Center site itself – so you could control which series in the file plan specific users would be able to see / file records into.

So from a capability standpoint, the 2007 release can certainly be used to enable a records management program of this type. But the underlying cultural challenges to getting such a program successfully adopted are still significant, and we’d strongly advise organizations considering this approach to think about how to mitigate those issues before proceeding.

Do the Content Type names used in the collaboration site need to be the same as those in the “Records Center”?

No. Thanks to the record routing list, you are free to have completely different names for Content Types in the Records Center vs. the collaboration sites that declare records. You can use the routing list to define how Content Types in those collaboration sites correspond to those in the Records Center.

This allows you to name Content Types in the collaboration sites in terms that are meaningful to your end-users (e.g. “Quarterly Filing”), while keeping names in the Records Center relevant for records managers (e.g. “SEC-regulated financial report”).

How do non-SharePoint repositories declare records using the Records Center “Web Service”?

The Records Center provides a public Web Service to allow any system to be able to declare records just like SharePoint sites can. (It also provides a public e-mail service --- but we’ll get back to that when we talk about the e-mail records management capabilities in the 2007 release of Microsoft Exchange in our next few posts.) But this raises the question – how does a non-SharePoint site, which doesn’t have a notion of Content Types, declare records?

The answer is that the definition of the Web Service requires only that when a record is declared, that declaration includes a textual property specifying the classification the sender proposes for that record. It’s then up to the Record Center to determine how to route the record, based on that proposed classification (using the information in the routing list).

When a record is declared from a SharePoint site, the name of the Content Type in that site is used as the proposed classification. However, non-SharePoint systems are free to specify the proposed classification for the record as they see fit. And to make it easier for non-SharePoint systems to declare records matching the record series in the Records Center, the Web Service includes additional methods to let those other systems query the Records Center to learn what the current entries in the routing list are.

For anyone interested in the specifics of this Web Service and how it’s used to declare records, we’ve included a code sample demonstrating it in our “Enterprise Content Management Starter Kit”.

Is the Records Center site (or any of the other features introduced to this point) available only for Microsoft Office documents?

Certainly not. We know that the requirements for records management are not specific to a particular file format, and that many records aren’t created or kept as Microsoft Office file formats like .doc, .xls, .ppt, etc. So we made a conscious effort in this release to ensure that our records management features work well for any type of file, including Office files, CAD, PDF, images, you name it.

The only features we’ve talked about so far that are specific to Office files (and require the 2007 release of the Office desktop applications) are:

· Document Information Panel: Without the 2007 Office desktop applications, users will be required to fill in document metadata using the SharePoint browser-based experience, rather than in the context of the authoring application.

· Policy Statement: Only Office files opened in the Office 2007 applications will prominently display to end-users the policy statement for those files.

· Client-side functionality of Labels and barcode policies: You can configure label and barcode policies for any type of item, and Office SharePoint Server 2007 will automatically generate labels & barcodes for those items. However, only Office files opened in the Office 2007 applications will prompt users to include those labels or barcodes in print-outs of those documents.

All of the other features discussed in this blog, including the Records Center site, treat non-Office files on an equal footing to Office files.


Thanks for reading, and please keep the questions coming!

- Ethan Gur-esh, Program Manager.

Comments (8)
  1. sam_n99 says:

    "only Office files opened in the Office 2007 applications will prompt users to include those labels or barcodes in print-outs of those documents."

    I am sure that microsoft can do more for supporting more types to print-out barcode or label, but microsoft want to force users to use Office systems only.

    What I can do if I have scanned docuemnts and need to include the barcode or label inside it to keep these documents trackable?

  2. Larry S says:

    I’d like to add barcodes and digital signitures to InfoPath 2007 forms that are displayed by the SharePoint Forms Server.

    Is there anyway to do this?

    We don’t want to force users to have the InfoPath client installed just so a barcode can be generated.

  3. @sam_n99:

    I take issue with this comment. I am aware (as all of you probably are) that in the past Microsoft has had a reputation of not playing well with other systems. However, we’ve gone to great lengths in the current release of Office SharePoint Server, and many of our other products, to be more open to working with other systems & file formats.

    That openness is particularly true with labels & barcodes: all of the information on the server about the barcode or label for a document or item (of any type) is exposed as item metadata using public interfaces that any application could use to provide the same functionality that the 2007 Office applications do.

    I don’t know of any other applications that have yet leveraged the barcode & label functionality of Office SharePoint Server 2007 — although we are working with many partners to help them better interoperate with all of our records management capabilities. But if there are any particular products or vendors you use that you want to see integrate these capabilities into their systems, I’d encourage you all to make this request from those vendors… and feel free to direct them my way if they need a Microsoft contact to help them with that integration.

    As for your other question about scanned documents: There are several options available to you here. The first one is to print out the SharePoint “properties” page for the scanned item — which will include its barcode — and attach that to print-outs of the scanned document. This approach has the benefit of ensuring that the barcode image doesn’t interfere with the original scanned document, for example by inadvertently covering text in the document.

    The second option is to insert the barcode into the scanned images when they’re ingested – this is something that would have to be done using whatever application you’re using to manipulate & view scanned images. The insertion can always be done by manually copying & pasting the barcode image… if you want a more automated solution, I again encourage you to either ask your current vendor to integrate with our barcode capabilities.

    – Ethan Gur-esh, Program Manager.

  4. Russell says:

    It’s possible that this has already been covered and I have just missed it somewhere but do Records Centers in any way deal with physical records?  By which I mean the traditional, hard copy, codafile-type files and their successive parts (frequently bearing unique id – aka file numbers).  Given the no-show of the paperless office most records managers are managing both electronic and physical records 9hybrid systems).  I can see how you are proposing that MOSS 2007 addresses the electronic content, but does it also support the management of physical records as well?


  5. @ Larry S:


    Yes you can. Digital signatures are supported in browser-based forms in InfoPath Forms Server 2007, via an ActiveX control. Here are some links to more information about this feature:

    – Webcast:

    – Training lab:

    (As for the “barcode” part of your question, I should clarify that the below answer applies to the barcode feature described earlier on this blog… if you’re looking for a way to use barcodes to encode InfoPath form data to facilitate data capture from printed/completed forms via OCR, that’s a different scenario and answer.)

    The barcode information on each form is stored as a metadata property, and as such can be surfaced within an InfoPath form (client or server) just like any other property. The only caveat there is that it’s probably easier to include the barcode value (i.e. the textual representation) than include the barcode image (i.e. an image)… which one you’ll want to surface in the form would depend on your scenario.

    Hope this helps,

    – Ethan Gur-esh, Program Manager.

  6. @ Russell:

    You’re absolutely right that physical records management is still a critical need for all records managers, and that we haven’t talked about it much on this blog… yet. I can assure this is NOT because we didn’t think about physical RM — I’m actually in the middle of writing up a post covering our physical RM in MOSS 2007, which will be posted in the next 24 hours. So please stay tuned, and hopefully the next post addresses your questions.


    – Ethan Gur-esh, Program Manager.  

  7. mkelly says:

    I’d like to customize the document libraries for Records Center so that I don’t have to go through each one manually and add columns.

    I’ve created a feature for a doc lib, but I’m having two problems:

    1) Is there a property that needs to be set in the feature library so that the Record Routing list will use it? I can’t use my custom library as it stands.

    2) What is the internal field name for the Hold Status column? Can’t seem to find that one.


    Mindy Kelly

  8. says:

    This is the third post in a series of posts about the Records Center in MOSS. ( Part One , Part Two

Comments are closed.

Skip to main content