Populating fields in SharePoint / InfoPath from query string parameters

As a follow-up to my previous blog post about hosting a web browser control in Dynamics AX, here’s a write-up on how I fudged a SharePoint page / InfoPath form to accept multiple field values from a query string parameter. To reiterate some of the background, the idea here was to be able to open up a new request in SharePoint, from Dynamics AX, with a few fields on the form pre-filled, so that the user wouldn’t have to copy & paste a bunch of stuff from AX into SharePoint.

My idea was to pass those values on the query string, which seemed pretty reasonable. I found some information on doing that with a bit of JavaScript, but that didn’t look like it would work well, for a form that had been created in InfoPath. So then I looked to the “query string URL filter web part”. This web part can be added to a SharePoint page, and allows you to pass a single query string parameter to a field on a SharePoint/InfoPath form. The big issue here is that it only supports a single parameter, so my plan to do something normal, like “?SO=S1234&PO=P1234&item=123456…” wasn’t going to work. After reading this blog post, and some other related posts, I came up with a plan to encode all of the values I needed to pass into a single parameter, of a form like this: “?param=SO:S1234|PO:P1234|IT:123456|…”. Not very pretty, but it would get the job done.

I mapped that one parameter to a hidden field on my InfoPath form, then added a bunch of rules to that field to break down the value and save the parts out to the desired form fields. There aren’t a lot of string-handling functions in InfoPath, but I found that substring-before and substring-after were enough for what I needed to do. A formula like this:

   substring-before(substring-after(URL parameters, "PO:"), "|")

can be used to extract the PO # “P1234” given an example like the one in the previous paragraph. This works, but it’s a little tenuous. If I had too much data to cram into the parameter, that would be a problem. Or if I had to worry about having special characters (like the colon or vertical bar characters) in the data fields, then that could confuse things quite a bit. But for my use, it works out pretty well.

I don’t actually do much SharePoint / InfoPath work. Every time I do, I feel like I’ve travelled back in time, to an era when InfoPath seemed like a good idea. (Though I’m not sure it was ever a good idea…) It doesn’t seem to have much of a future, though Microsoft will support InfoPath 2013 until 2023.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.