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.

3 Responses so far.

  1. sukumar says:

    That't really wonderful article about SharePoint and Thanks for sharing information. your are really great. keep it up more post about SharePoint. our company also providing SharePoint Platform.Sharepoint Development

  2. Joe Roush says:

    Good post about forms vs documents. This frequently comes up where I work as well

  3. hanumant says:

    Heya¡­my very first comment on your site. ,I have been reading your blog for a while and thought I would completely pop in and drop a friendly note. . It is great stuff indeed. I also wanted to there a way to subscribe to your site via email?

    Document Management Systems