My career in technology

(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:   

  1. 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.

You will need to check the "Allow users to edit data..." checkbox for the workflow to be able to edit the fields.

When you do, you will get the warning shown here, and you understand why I categorize this as a risk.

  1. 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.
  2. 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:   

  1. 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).
  2. Upload the “foreign” form to the “transition” library.
  3. The workflow runs (either automatically or manually), copying the data to the destination item in the destination library.
  4. “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!

More posts about InfoPath.

More posts about SharePoint.

About these ads

Comments on: "A No-Code Solution to Host an InfoPath Form in Multiple SharePoint Sites" (6)

  1. [...] (Update: I’ve figured out a second way to migrate the form using no code.) [...]

  2. [...] “Publish an InfoPath Form to Multiple SharePoint Sites”, and its no-code companion, “A No-Code Solution to Host an InfoPath Form in Multiple SharePoint Sites”, have generated a lot more traffic than just about any other post I’ve made (excepting my [...]

  3. UPDATE!!

    A way to mitigate (though not entirely remove) the risk of promoting the fields to user-editable using a view.

    If you set the default view to use “Name (linked to document)” instead of “Name (linked to document with edit menu)”, the user does not have an easy way to get to “Edit Properties”. This won’t stop someone determined to get to it if they have the skills to do so, but it prevents accidental changes or someone who thinks they know what they are doing from doing it wrong.

  4. Very interesting 2 approaches. In this case Event Receiver really does seem superior although I normally plum for the codeless soloution

  5. Christine Lambden said:

    When I googled to find a way to publish a form to two separate libraries, I wasn’t particularly confident that I would find an answer. Thank you for providing not one but two! Silly me — should I have searched your site first. You are the guru, after all. Keep up the good work!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 877 other followers

%d bloggers like this: