(Updated! See the comments…)
In addition to my method of using an Event Handler to make it possible to host an InfoPath file in multiple locations, I have figured out a way to host an InfoPath form in multiple locations and be able to transfer form data from one location to the other and be able to open the forms on each site, without writing a single line of code. There is some risk involved with this process, and if the form is long there will be quite a bit of configuration work to make it go, but otherwise the solution is pretty simple.
You can, of course, use an InfoPath form template to publish to as many locations as you desire, but the form data produced will only look to the library from which it was created for the form template.
As I hypothesized in my previous post, there is a use case in which a form needed to be hosted on two networks that could not talk to each other, but the form file could be sent from one network to the other (via e-mail, sneakernet, whatever). The form was initiated on one network and fields were filled in, then the form needed to be transfered to the other location for completion.
Risk of my no-code solution: The process involves promoting all form fields and making them user-editable outside the control of the business logic enforcement of the form.
If the risk is acceptable, here’s what to do:
- Use the InfoPath .xsn form template to publish the form to each of the locations you want the form to reside. All fields must be promoted and user-editable.
- Publish the form to an additional “transition” library on the destination site. If you are moving the forms both ways, each site will need a transition library. Again, all fields must be promoted, but are not required to be user-editable.
- Build a workflow in SharePoint Designer.
This is the tricky part.
The workflow would be configured to start when a new item is created in (or, in other words, a form .xml file from a “foreign” source is uploaded to) the “transition” library. (However, you could set it for manual start, if users didn’t mind going through the extra steps every time).
The Action would be Update List Item, updating an item in the destination list (library).
In the Update List Item dialog, set each of the fields in the destination list (library) to the values of the fields in the source list (the “transition” library). (As I said, if the form has a lot of fields, there will be quite a bit of configuration to get this done.) Then, set the Find the List Item to use data in the source list to identify the destination list item in the destination list.
The workflow could finish by deleting the original form from the “transition” library, if retaining it was not required or desired.
The process would work like this:
- You create a new blank form as the “destination item” in the destination library with the correct form name. If you have required fields in the form, you would either need to have form logic disabling the requirements for the creation of a destination file, or have dummy values in the required fields. This can make things even more complicated when what fields are required changes depending on the state of the form – on one domain the required fields are X and Y, and on the second domain the fields are X, Y and Z. Putting a dummy value in Z during the creation of the destination item satisfies the need for data, and so the dummy data might not be changed when the form is actually being filled out, but putting in logic to reject dummy values would prevent the creation of dummy values when creating a destination item. Not an insurmountable problem, but a problem that should be considered, whose solution I leave as an exercise to the reader (primarily because its solution is dictated by the specific needs of the form logic).
- Upload the “foreign” form to the “transition” library.
- The workflow runs (either automatically or manually), copying the data to the destination item in the destination library.
- “Foreign’ form is deleted, if desired/required.
It may be possible to use a single library to do all of this (just have the workflow point to the same library that the source file is in). I would imagine you would need to apply a naming convention to the uploaded “foreign” forms (like tacking the word “external” to the end of the file name during upload) then using the workflow to use the naming convention to name the created list item correctly. You could even configure the view to exclude all files that match the naming convention of the “foreign” files.
Let me know how it works for you, and what problems you encounter!