Saturday, September 8, 2007, SharePoint, and InfoPath Best Practices

This is the fourth of a series of best practices I considered when starting a new workflow. Note that manye of these Best Practices are 2003 specific. They will be re-evaluated with the new BlackPearl release.

1) Store InfoPath Data Externally
Commonly much of the data within an InfoPath form needs to be reported on. It is recommended that this data be stored externally for robust data reporting requirements.

When using InfoPath processes, a good practice is to keep the data in the InfoPath form while it moves through the process. Then at the end of the process, shred the XML apart and insert it into a normalized database. As well, at various points in the process, push the XML document out to a different InfoPath form library where users can get access to the latest and greatest data.

2) Create Reusable XML Web Services
In many cases both the InfoPath form and the process will require access to the same data. Use XML Web Services to allow both to gain access to the same data.

3) Required Fields with InfoPath
In InfoPath setting a field as required will make the field required for all users who will submit the form. If there is a simple process with two InfoPath activities the first being for a submitter and the second being for an approver. If there is a field called “IsApproved” and is defined as required in InfoPath the submitter would have to fill this in even though this is something that only the approver should do. There are two ways to get around this:
  • Introduce a field into the InfoPath form that will be set by to indicate the state of the workflow (very similar to switching the view). This can be evaluated in validation rule of the field and defer the validation of a field to specific points in time.
  • Break the InfoPath form apart into two separate workflows.

4) Remove Views and Create a Single View
If you have many views (let’s say more than three) and you commonly have to make changes in each and every view every time there is a change, consider collapsing down to one view. Again introduce a state field into the InfoPath form that will be set by Then InfoPath can use conditional formatting to hide those fields based upon the state of the workflow.

5) Multiform Processes
BlackPearl now provides the ability to create multiple InfoPath forms and use them in the same process. In 2003 it was possible to create workflows with multiple InfoPath forms by creating a master process and then creating child processes for each form. Another approach is to just chain several InfoPath form processes together. The advantage of having a master process is that you can map out how all of the InfoPath child processes interact with each other as well as have global events.

6) Understand Limitations of InfoPath
Do not let InfoPath become a substitute for creating Win Forms applications. In the end InfoPath should be used to capture data from a user. Robust functionality to view databases, provide heavy user interactions, etc. should be done in other mediums. One indication this is occurring if there is heavy use of script Managed Code in the InfoPath form.

Note that an InfoPath process does NOT have to be initiated by an InfoPath form. External system,, Win Forms can start a process that later uses an InfoPath form to capture some data.

7) Solidify XSD First
It is very important to try to have your XSD schema fairly solid prior to enabling your InfoPath form. Once the Form is enabled, it must remain in sync with the cached XSD schema within

8) Do not Pollute XSD
Over time the InfoPath form will become polluted with various nodes that are used to support the presentation of the InfoPath form (two of the recommendations above violate this rule). It is recommended to keep this to a minimum. If it cannot be avoided place the nodes related to the InfoPath UI in a separate group (title as such) so that is it immediately known which nodes contain valid business data and which ones do not.

9 ) InfoPath Version Control
For 2003 when a change is made to an InfoPath form this must be carefully considered when publishing it to SharePoint as running process instances will be affected. InfoPath will try to gracefully handle situation when opening up an old XML file within a newer version of the InfoPath form. This will not always result well. It is suggested that a different form library be created for each version of the form. The running processes are configured to use the old form in the old form library while the new process instances will use the new form in the new form library.

10) Do not Use Attachments in InfoPath
Do not put attachments into the InfoPath form as this can cause significant performance problems. Large attachments will be stored in the InfoPath XML which is then stored in the database. The XML for an InfoPath form is used at both the process and activity levels. This creates the possibility the same attachment being stored hundreds of times in the database wasting space. It is recommended that the InfoPath form store all of the documents directly into something like SharePoint and then provide links to those documents inside the InfoPath form.

11) Securing InfoPath Data
Switching InfoPath views is NOT a valid way to secure data as the user can simply open the XML directly and modify the data directly. One way to enforce security is to use multiple document libraries with permissions. There is no way secure an InfoPath form at the document instance level with WSS 2.0. This can possibly resolved with using WSS 3.0 with BlackPearl as permissions can be applied at the document item level. If data must be totally secured, store all of the XML data in an external database.

12) Viewing Forms in Process
A common request by users is to be able to review the InfoPath form after they have submitted it or when the process is complete. The InfoPath form that was in SharePoint is dynamically added and removed by when an InfoPath client is completed. It is suggested that the form be published at specific points in the process to various archive document libraries for all users to access.

13) Process and Activity Level XML and Multi-Destination Considerations
Understand that when an InfoPath form is attached to a 2003 process the wizard will go into the InfoPath form and retrieve the XSD. The XSD will be copied into the process definition as a process level XML data field. For InfoPath activities within that process each will have an activity level XML data field created for the InfoPath client event. This is done because there is a possibility that multiple destination users can be added to the activity. This is important because each destination user should have their own copy of the InfoPath XML to modify as succeeding rules will need to evaluate the data set by each approving user (remember that rules can be created that more than one user must approve before an activity can be completed). It would not be possible to create succeeding rules requiring multiple user approval if all the users shared the same XML document.

If there are events after the InfoPath client event in the same activity make sure to use the activity level XML and not the process level XML. The process level XML will be updated in the succeeding rule of the activity which is at the end of the activity life-cycle.

If there are many destination users that are able to approve an activity, place custom data aggregation code into the succeeding rule as this is where data is re-synchronized with the process level XML data field. An example is that if three users and each add three items to the InfoPath form, you will need to add to the succeeding rule to ensure there will be nine items in the process level XML data field. Otherwise the last three will only be moved up.

It is highly suggested that if there are multiple destination users for an InfoPath client event that a unique name is used for the InfoPath form for each destination user. If multiple destination users modified their own specific XML and this needs to be aggregated at the end of the activity, modify the succeeding rule code to merge this data together back into the process level XML data field.

14) Reuse WSS Services provides several useful ready to go services to do various things within SharePoint like uploading/deleting files, creating/deleting folders, creating/updating document metadata, etc. These services can be easily reused within InfoPath, and Win Forms.


Chris O'Connor said...

Great articles - looking forward to seeing some of your posts about K2[blackpearl]

WhyOh said...

If my process that completed by InfoPath 2003 form, how I open that from for InfoPath 2007 version. Please help me.

Jason Apergis said...

Need a little more information - little confused on what you want to do. Are you saying you have some XML that was saved in InfoPath 2003 but now you want to open it in InfoPath 2007?

Senthilkumar Selvaraj said...

I am very new to and Infopath.

"Then at the end of the process, shred the XML apart and insert it into a normalized database."

can you give me some directions or advice on how this is done.

Jason Apergis said...


I was being pretty generic when I said shred XML. However there of so many ways of doing this. A few that come to mind are:

- Put rules in the InfoPath form that will submit the XML to a custom web service that will save the data to a database.
- If you have K2 blackpearl, take the same approach but use an InfoPath integrated SmartObject datasource that will save the XML of the form on submit.
- You can call a web service from the K2 process to save the XML from the process level xml fields.
- You can call a custom API from the K2 process to save the XML from the process level xml fields.
- You could use SmartObjects in a K2 process to save the XML from the process level xml fields.

In this blog I show how to access the XML fields in a K2 server side event. Once you get to the XML, if you know .Net dev, you should be off and runnig :-)

Senthilkumar Selvaraj said...

Thanks for your help Jason. I went for the smartobject method as did not involve any coding and my requirements were quite simple.

Now, I am trying to following your best practice of creating a single view for the form. Can you give me some tips on implementing that. Being a beginner, I am unable to figure out how to implement it.
Thanks for your help again.

Jason Apergis said...

Do feel that you have to use a single view. Sometimes having many views is ok. However if you have big forms with lots of rules or if every very is exteremly similar might as well just use one view.

When using one view, you will notice in the InfoPath form main datasource that there is a new _K2 node. In that node there is a DocumentView field. It will be populated by K2 with the name of the activity. You can use that to do specific validation associated to that step in the process.

Also - we have a K2 book that is being published by Wrox. I wrote a few of the chapters and we are in the final review stages with the publishers. I will make an announcement when it is finished. The publish date on Amazon is wrong -

Senthilkumar Selvaraj said...

Thanks Jason, that was very helpful. I am looking forward to the release of your K2 bp book.

Unknown said...

I have gone through some of your blogs and its very intresting and informative. Good work and every blog is worth appreciation. I have started working on K2 Black Pearl and the labs on VPC from K2 are well organised and it all works fine with in VPC coz all the wiring is ready done. However when I am trying to recreate some of the samples in our environment its going no-where. Its all coz there is one major bit missing from the K2 end which they have not included or probably I am not able to find one, AN ARCHITECTURAL DIAGRAM of what's sitting where, what makes the K2 in its entirity and ralation to other products. If you could kindly draw some high level diagram with few tips on each block and publish it, it would be of great help. Look forward for you reply and also look forward for your book to be out soon. Good Luck.

Jason Apergis said...


Did you look at all at the 0803 SDK? There is some stuff in there.

I do have some context diagrams I have drawn for clients to explian where K2 sits within the MS eco-system, but they are high level. What sort of specifics are you looking for. Just an understand of how K2 integrates with SharePoint, InfoPath,, BizTalk, Custom Apps, etc?

Here is one I have on SmartObjects which was cleaned up for the book.