Sometimes I wonder if InfoPath can be used in a scalable solution. Though I have searched in web for any use cases, I've not seen examples citing InfoPath being used in a scalable deployment.
Recently, I too faced a challenge, posted the problem in MSDN forum, but didn't get any solution and then came up with "workaround" to resolve the matter. Considering this could be one of the cases which peple often encounter, I thought of detailing the information in this post.
Scenario:
1. Version: SharePoint 2010 and InfoPath 2010.
2. Design an InfoPath form (browser based) and publish it as Farm administrator approved template.
3. Activate this form in a site collection.
4. Add the above form as content type in a document library.
5. Now, it is available for user to fill up the form and save.
----At this point, user has saved the form----
6. There is a change request for InfoPath form, so go ahead and change the design.
7. Publish again as before.
8. Notice that, user filled form (step 5) is reflecting the changes.
This behavior could pose a problem when user filled forms get into approval channel and are used in an Audit. Any changes to the form which is already approved is sometimes not acceptable to the users.
Now, the question is how do we avoid existing forms getting affected from future changes.
Options Explored:
1. Open the form in InfoPath Designer.
2. Navigate to File -> Form Options -> Versioning.
3. If you observe here, there are two options to set.
3a. Update Template, which I set it to Let form users decide when to update.
3b. Update existing forms, which I set it to Do Nothing.
Unfortunately, none of these settings had any impact on the existing form. I wonder if these settings apply only to Offline Forms (which I did not test though as in my case it was browser based form).
Another option tried was setting Update existing forms to "Use custom event". Idea was to cancel Version Upgrade event. But this option also had no effect on the existing form.
Solution (Workaround):
1. Open the form in InfoPath Designer.
2. Place a text box control on the default view of the form.
3. Call this text box as txtVersion, set the default value to 1, and make it hidden by applying a formatting rule.
Next time when there is a change requirement,
4. Open the form in InfoPath Designer.
5. Create a replica of the default view into another view (call it V2).
6. Go to default view, set value of txtVersion to 2.
7. Create a rule in form load such that if txtVersion = 2, switch to view V2.
8. Publish the form (Ensure the version settings are set as described above under points 3a and 3b).
Now, all the existing forms keep showing old version and the new forms show modified version.
Note: Yes, this might not be the efficient way of implementing it, but considering other options are not working, this solution would suffice the need. However, this solution becomes more complicated if the InfoPath form itself requires multiple views for users. Also, if the changes are frequent, the above method unnecessarily increase the content of the form and might become performance issue. So, this approach should be considered after weighing the requirement and needs and taking into consideration other factors.
If you have any other approach to resolve, would love to hear that. Please do leave a comment.
Recently, I too faced a challenge, posted the problem in MSDN forum, but didn't get any solution and then came up with "workaround" to resolve the matter. Considering this could be one of the cases which peple often encounter, I thought of detailing the information in this post.
Scenario:
1. Version: SharePoint 2010 and InfoPath 2010.
2. Design an InfoPath form (browser based) and publish it as Farm administrator approved template.
3. Activate this form in a site collection.
4. Add the above form as content type in a document library.
5. Now, it is available for user to fill up the form and save.
----At this point, user has saved the form----
6. There is a change request for InfoPath form, so go ahead and change the design.
7. Publish again as before.
8. Notice that, user filled form (step 5) is reflecting the changes.
This behavior could pose a problem when user filled forms get into approval channel and are used in an Audit. Any changes to the form which is already approved is sometimes not acceptable to the users.
Now, the question is how do we avoid existing forms getting affected from future changes.
Options Explored:
1. Open the form in InfoPath Designer.
2. Navigate to File -> Form Options -> Versioning.
3. If you observe here, there are two options to set.
3a. Update Template, which I set it to Let form users decide when to update.
3b. Update existing forms, which I set it to Do Nothing.
Unfortunately, none of these settings had any impact on the existing form. I wonder if these settings apply only to Offline Forms (which I did not test though as in my case it was browser based form).
Another option tried was setting Update existing forms to "Use custom event". Idea was to cancel Version Upgrade event. But this option also had no effect on the existing form.
Solution (Workaround):
1. Open the form in InfoPath Designer.
2. Place a text box control on the default view of the form.
3. Call this text box as txtVersion, set the default value to 1, and make it hidden by applying a formatting rule.
Next time when there is a change requirement,
4. Open the form in InfoPath Designer.
5. Create a replica of the default view into another view (call it V2).
6. Go to default view, set value of txtVersion to 2.
7. Create a rule in form load such that if txtVersion = 2, switch to view V2.
8. Publish the form (Ensure the version settings are set as described above under points 3a and 3b).
Now, all the existing forms keep showing old version and the new forms show modified version.
Note: Yes, this might not be the efficient way of implementing it, but considering other options are not working, this solution would suffice the need. However, this solution becomes more complicated if the InfoPath form itself requires multiple views for users. Also, if the changes are frequent, the above method unnecessarily increase the content of the form and might become performance issue. So, this approach should be considered after weighing the requirement and needs and taking into consideration other factors.
If you have any other approach to resolve, would love to hear that. Please do leave a comment.
Sounds like a great idea to me. Like you, I have already tried changing Form Options, and there was no effect. But I'm working with cascading dropdowns querying from a SharePoint list that will change every few months, so I really like this idea for keeping the old forms exactly as they were.
ReplyDeleteThanks Christie for the feedback.
ReplyDelete