Sunday, June 20, 2010

Document Management & SharePoint: Forms vs Documents

I’ve spent the last couple of months developing a customized document management system in SharePoint 2007 for a client.  Many interesting challenges have surfaced as a result of working thru the different requirements for this solution, and I thought it might be useful to write about them.  Check back from time to time to read the ongoing saga.  Now, of course, it would be a miracle if I were able to discuss them here in any kind of logical order, so I’m going to settle for random thoughts instead. :)

The first random thought as it relates to document management is the use of documents and forms in a document control solution.  Out of the box,  SharePoint has preconfigured Document and Forms libraries to help you get started using both.  But as you audit your own existing files in preparation for a migration into SharePoint, it can imagesometimes be unclear which of your files are forms, and which of them are simply documents.

For example, when identifying Forms, it can be very easy to simply say that all existing InfoPath documents are forms.  InfoPath forms have fields that need to be filled in, and usually have a Submit button of some kind.  But many organizations also use Microsoft Word or even Excel to create and use as Forms.  These Word or Excel documents also have open fields that expect data, and many times are filled out by first being printed to paper.  But it gets even better!  These Word documents could very closely resemble Word templates – files meant to be used as starting points for other Word documents, which also could have data-ready areas within them.  Now the distinction between forms & documents starts to blur a bit.

How, then, do we decide whether a particular Word document in this scenario should be a form or a document in our new SharePoint document management system?  This is a crucial piece of information in the design of our solution, as we consider which library to place the document in, whether the document should be converted from Word to InfoPath, etc.

If you were to ask me to give you an elevator pitch version of an answer, I would say this:  a form is a file whose primary intent is to ask a question, and a document is a file whose primary intent is to answer a question.

I know this won’t satisfy my more cerebral readers, so I scoured a bunch of word definitions and came up with a slightly more specific answer:

Document – A physical or digital representation of a body of information designed with the primary intent to communicate/provide said body of information.

Form – a physical or digital file containing spaces (fields) in which to write/type/select, and whose primary intent is to capture/consume/store information.

Template – a physical or digital file containing information that is meant to be replaced/extended , and whose primary intent is to be used to begin or guide the creation of another file.
  • A form without data is a template.
  • A document with areas intended to be filled-in is a template.
In future posts, I’ll dive a little deeper into what these definitions mean to us as we design & develop our SharePoint-based document management system, including records management.


  1. Sharepoint remains to be a top DMS and a lot of migration from physical papers are being transferred into their system.

    electronic document management

    1. This is a very insightful discussion between forms and documents. I didn't really think there was a debate at first.



  2. This is a very insightful discussion between forms and documents. I didn't really think there was a debate at first.

    long island document scanning