Building SharePoint-Friendly File Plans using InfoPath 2010

Configuring a SharePoint 2010 records center site involves many steps that must be properly orchestrated in order to achieve the desired results.

As an example, most records management solutions use content organizer rules to route incoming records to a particular document library or folder so they can be associated with specific information policies and retention schedules.  But configuring the content organizer requires that the site columns, content types, document libraries, folders and other components are constructed beforehand. The situation is even more challenging when working with target locations external to the site collection being configured.

Note: You can download the code for this solution here: 

SharePointArchitects.FilePlanner.zip

In this slide presentation, I show how InfoPath 2010 can be leveraged to reduce the complexity of records center configuration by capturing all of the required elements in one place, and then pushing them out in various ways, depending on your overall information architecture strategy.

Building and Using SharePoint-Friendly File Plans

 

 

, , , ,

4 Responses to Building SharePoint-Friendly File Plans using InfoPath 2010

  1. Guy July 13, 2012 at 9:33 am #

    Can you discuss the dependencies for this? I’m getting an unresolved reference upon activation – I’ll be able to track it down eventually….

    • John Holliday July 13, 2012 at 9:42 am #

      @Guy – The solution is self-contained (no external dependencies). I’m assuming that since you were able to deploy the solution package, you were also able to build it, so the assembly references would have been resolved prior to deployment. What is the exact error message you are seeing during feature activation?

      • Guy July 13, 2012 at 9:54 am #

        It looks like the feature receiver for the File Plan Template is missing, so the corresponding content type never gets created..

        • Guy July 13, 2012 at 10:09 am #

          Yes, it needs the XSNFeatureHandler and to have the white space squeezed out of the constant in the

          const string FILEPLAN_TYPENAME = “FilePlanTemplate”

          I actually use a custom XSN feature handler that respects the fact that a form has been published as a content type that contains site column mappings.. It’s one of the nusiance areas of SharePoint for me.. It keeps from having to maintain copies of SharePoint forms that haven’t been “tainted” by virtue of being published via the UI as content types.

Leave a Reply