Emailing Links to InfoPath Forms

jscookster — Thu, 23 Mar 2017 00:23:00 GMT

Sometimes you want your users to be able to open forms without having to navigate to SharePoint and open up the associated form library. Sometimes you want them to do it without even having to log into the SharePoint site: maybe your end users don’t even have SharePoint accounts! Today’s blog post will give you a few tips on how to accomplish these and other goals.

To give your end users the ability to open a form from outside the SharePoint library, you need to know the syntax of an InfoPath form link. Let’s look at a sample link in detail. Suppose you have SharePoint site called http://www.MyShPSite.com, with a sub-site called MySubsite, and an InfoPath form library called MyLibrary. There are many different query parameters for an InfoPath form link, most of them are optional so we’ll only cover the necessary ones--- XsnLocation and XmlLocation---in this post. (You can read more about the other query parameters here.)

New Form Link:

http://www.MyShPSite.com/MySubsite/_layouts/FormServer.aspx?XsnLocation=https://MyShPSite.com/MySubsite/MyLibrary/Forms/template.xsn

Existing Form Link:

http://www.MyShPSite.com/MySubsite/_layouts/FormServer.aspx?XmlLocation=/MySubsite/MyLibrary/MyFormName.xml

(Note: to open existing forms, you’re going to need to make sure you are using a unique naming convention for your forms! Otherwise if you have three forms all named 2016-12-25.xml, how will InfoPath know which form to open?)

Ok, now that you have your link, how do you get it to your users? Well, the easiest way is to send them an email with the link. To do this, you’ll need to download a nifty tool called SharePoint Designer – it exists in both 2010 and 2013 varieties, download the one for whichever flavor of SharePoint your site is running on.

Now that you have downloaded your designer tool, switch back to InfoPath. Whatever naming convention you’re using for your forms, store that value in a text field in your schema. I’d suggest calling this field FormName or something similar.

(Note: if you only want to send links to new forms, you can skip this FormName stuff and go straight to the FormLink part down below.)

Now add another text field called FormLink, and set the default value of that field to the following hardcoded value for a new form:
http://www.MyShPSite.com/MySubsite/_layouts/FormServer.aspx?XsnLocation=https://MyShPSite.com/MySubsite/MyLibrary/Forms/template.xsn

…or this formula for an existing form:

Now promote that FormLink field by going to File à Form Options à Property Promotion and adding FormLink to the list:

Republish your form to your form library, then open up your site in SharePoint Designer. (If you don’t have SharePoint Designer, you can download it for free here.) Navigate to the Workflows page then add a new List Workflow. Select the name of your form library, then name your workflow (mine is called Send Email).

Now you need to create the email template. In the WORKFLOW ribbon at the top of SharePoint Designer, select Action à Send an Email. Open up the Email Designer, select a recipient, type a subject heading and body text, then type the text you want to describe your form link. Highlight this text, then click the Hyperlink icon to bring up the Edit Hyperlink popup menu. Click the fx button on the Address line, then select the Form Link promoted property from the source field dropdown in the String Lookup popup window. Click OK to close out all of these windows.

We’re almost done: go back to the Workflow Settings page (Workflows à click the name of your workflow) and edit the Start Options. Select the checkboxes that correspond to your particular use case. In mine, I want the email workflow to run when a new form is submitted and when an existing form is resubmitted, so I have both of the bottom boxes checked.

And finally, make sure to Publish your workflow to your SharePoint site by clicking the Publish icon at the top left of SharePoint Designer.

That’s it! Now each time your workflow runs, and email will be sent with a link to your form (or to open a new form, if that’s the option you selected way back at the beginning of this tutorial).

Emailing Links to FormsViewer Forms

FormsViewer is a great alternative to InfoPath. Links can be opened on mobile devices and you have the option for anonymous opens. You can also send links to FormsViewer forms, but because those links are slightly longer you’ll need to make a few adjustments to the above process.

If you have FormsViewer installed on your SharePoint site, you can copy the link to open a new form by right-clicking on either the Open Form button or the Open Form (anonymous) button.

Once you have your link copied down somewhere, you will go through the same process described above to promote your Form Link field, with one special modification: you need to first create a Site Column on SharePoint, and then promote the Form Link field to that specific column.

Here is a tutorial on how to create a SharePoint site column (make sure the one you create allows multiple lines of text).

Once your site column is created, you will need to associate the FormLink field with that site column by re-publishing your form the long way (do NOT edit the Promoted Properties menu in InfoPath – that way won’t work!). Go to File à Publish à SharePoint Server to bring up the Publishing Wizard, then Next-click your way through the wizard without changing anything until you get to the promoted columns list. Click the Add button, select your FormsViewer FormLink field from the list of schema fields in the popup window, then select the Custom Columns site column group, and select the name of the site column you created in the previous step (I named mine FormsViewer Link). Click OK, Next and then Publish.

The steps to create an email workflow are the same for FormsViewer, so that’s it for configuring an email workflow to send a link to open a FormsViewer form!

xPaths With Double Forward Slashes Can Prevent Browser Publishing

JenniferLindsay — Wed, 02 Jul 2014 22:23:00 GMT

If you use InfoPath long enough, you will eventually run into a browser publishing error message something like this: "The form template has been published to the server but it can only be opened in InfoPath Filler."

Often the message will tell you to examine Design Checker and resolve any errors that appear there, but if there aren't any errors then this message can feel quite frustrating. Your next step in troubleshooting should be examining the SharePoint logs, but that's not possible if you have a cloud-based installation, such as Office 365, and there's no guarantee the logs will contain useful information. Another tool that can help with troubleshooting is Fiddler, a simple desktop application that allows you to examine the web traffic that is sent back & forth between InfoPath and your SharePoint server during the publishing process---but again, no guarantees that that traffic will contain the answer.

If you've tried all these steps and still don't know what's going wrong, then usually (a) there is a configuration issue with your SharePoint server, or (b) InfoPath has failed to catch an error in your form template. A few weeks ago, I discovered one of these types of errors after a long painstaking search. I'm posting this blog to give you a heads up, in case you've got a similar undetected error in your own template.

For some reason, InfoPath will verify xPaths that contain double forward slashes, like the following:

xdXDocument:GetDOM("Status")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW//d:ID

In other words, if you have a double slash inside an xPath expression in one of your rules, then InfoPath won't detect it and will treat the xPath as valid.

If you then try to browser publish a form containing such an expression, IPFS---InfoPath Forms Service, the server-side web service that converts templates to browser forms---will throw an error and only publish in filler mode without telling you why. What's more, the associated SharePoint logs won’t point to this xPath as a source of the error, leaving you to find this only by trial & error debugging. Isn't that wonderful?

Now, before you throw up your hands and say you don't have the time to manually examine every single rule in your complex form template, there's an easy way to do this: export the source files (File -> Publish -> Export Source Files) then find the file called manifest.xsf and open it in a text editor, such as Notepad. Then simply search for "//my" and, if you have any data connections in your form, also search for "//d" - this will locate only double forward slashes in the xPath expressions in your template.

So, next time you get a browser publish error alert and InfoPath's Design Checker doesn't show any errors, check your xPaths and see if any of them contain double forward slashes.

Happy Form Designing!

~Jen

Jennifer Lindsay

Emailing Links to InfoPath Forms

xPaths With Double Forward Slashes Can Prevent Browser Publishing