Tech Trek – 2012.01.22 Sunday
I’ve recently updated an InfoPath form template for a project and ran into the following Microsoft Support issue KB2554288.
Unfortunately, I read this knowledge base article after I had already published the InfoPath template into a second form library to “test” the changes I plan to apply in production. I didn’t intend to implement the suggested resolution of publishing the template as a Site Content Type, or creating Site Columns since it isn’t going to be reused anyway.
With this data at hand, I proceeded to delete the second library even before re-publishing the production form template. As indicated, the promoted columns were re-created when publishing a form more than once within the same SharePoint site. In my situation, this resulted into the following issues to the original form library:
- Promoted columns were removed in list views
- Calculated columns resulted into invalid values (#VALUE) even if column names are the same
- Custom workflow lookups didn’t resolve the promoted columns
Luckily, my form was not too complex but I had to perform these steps to correct the form library:
- Re-create the list views
- Re-create the calculated columns
- Modify custom workflows in SharePoint Designer and later re-published them to the site
GAPS AND RECOMMENDATIONS
It was a good thing that I had backup of the configuration settings so I will able to re-create them as needed. Thus, it would be nice to have a SharePoint tool to create documentation about configurations. Also, the ability to restore custom workflow would be helpful in case of a worse-case scenario of re-creating the library or list.
SUMMARY
The intent of this post is to shed light on some of the nuances of InfoPath development as compared to the traditional deployment procedures into a test or staging environment. Thus, it introduces additional work for SharePoint Administrators when applying “change control” practices and poses a challenge when trying to adhere into legal compliance scenarios.
It does take a different mindset coming from strict software configuration management (SCM) principles in my previous work experience. What we’ve done in our organization was to store application configurations in transactional database tables and XML files coupled with version control system which made auditing changes more feasible.
