I ran into an interesting technical scenario while building InfoPath forms that interacted with a custom list in SharePoint 2010. Creating the InfoPath SharePoint List Form was straight forward and not a problem. I had to create roughly five different views of this edit form, one for each step in the approval process. The design goal was to have InfoPath forms that can easily hook into the custom list, allow any non-developer the ability to update the look and feel of these forms. The end solution was to have a workflow send out emails during each step of the workflow with a link to the InfoPath edit form and ID of the list item. Doing this in 2007 was a breeze, I figured this would be straight forward but ran into an issue.

SharePoint 2007 editforms were easy. You could convert the editform webpart on a custom page (or modify the editform.aspx page), make your XSLT changes manually, or just change them visually through SharePoint Designer. If you looked at the default editform.aspx when editing an item, the path to editform.aspx always had ID=some number that was the ID of the list item. Now, SharePoint 2010 hides the URLs using javascript when you edit a page, but you can still format an edit URL the same way you did in SharePoint 2007. Here is an example:


So, even though SharePoint 2010 hide this through the JavaScript links, you can still access the edit form in the same method, so building workflow strings to the edit form is not an issue.

Now, when you publish an InfoPath form as an edit form for a custom list, it uploads the template to a new folder within the list, along with new edit forms and new forms. The new URL structure to the edit form that uses InfoPath would be:


Now that I created my edit form in InfoPath, I was able to pass the ID value using the URL above and edit that item to see that it is working as expected. Here is where things get interesting…

When you are in InfoPath, you can set the default view of the edit form inside of the InfoPath Designer form itself. You can add more than one view that is literally a different view for editing. I created a view for each step of my workflow process which was flawless. Since I wanted to use different forms for different views of the data (simulating the workflow steps before coding the workflow), I looked for a way to change the default view of the list using a query string, just like you can do with the list view. Turns out there is no query string value (that I could find) to call out the InfoPath Edit Form view I wanted.

Next thing I tried was creating custom pages within a pages library containing the InfoPath Form Web Part on a web part page. In the web part properties, I can define the list (which sees my custom list that the InfoPath form is tied to), set my other properties such as the default view for that page, and the view comes up no problem. I noticed that I could not pass the ID value to a web part page, it was not returning data. I tried passing along the list=value with the List GUID and the ID value, still did not work. Using a QueryString filter web part did nothing for the InfoPath Form web part. I tried another clever approach of copying the pages I had already created with the InfoPath web parts on them into the “item” folder of the list where the editifs.aspx page resides. That threw up an error. Then it dawned on me… create the page in SharePoint Designer!

Here are the steps I used to solve my technical issue:

  1. Browse to the “item” folder contained within the custom list using SharePoint Designer 2010.
  2. Make a copy of the editifs.aspx page and rename it.
  3. Edit the copied and renamed version of the editifs.aspx page in SharePoint Designer.
  4. Highlight the InfoPath Form web part on the page, and pull up the Tag Properties pane for the object.
  5. I added the view name for my edit form under Misc > DefaultView
  6. Save the page and tested using the ID query string value.

That was all it took to get different URLs tied to the same list for different edit form views of the list item. You would think that intuitively you could set the default view of the edit form for each different page, but not unless you use SharePoint Designer. Yes, you can set a single default edit form view using InfoPath, set the default view on an InfoPath Form Web Part, but you cannot set multiple “default views” without using the approach mentioned above. Regardless, this was easy enough to figure out and can be packaged up nicely using a list template!