Making the Best of InfoPath

 

A couple of years or so ago Microsoft announced that InfoPath was dead, the crowd cheered. Microsoft showed some new forms technology at the SharePoint Conference – and they were all, well, terrible. Which is why a year or so later InfoPath is back, it will be fully supported in 2016. Now I’m sure they were all hoping for cheer again that it was back,  but not me. I’d like to say InfoPath is dead to me – but many clients are still using it, and need help digging themselves out of the holes that InfoPath has led them into.

Whether it’s creating a new view and edit form for a SharePoint list or creating a new form for a forms library, I see a lot people with the same issues and falling into the same traps. Where possible I like to steer my clients towards using alternate forms technology, perhaps the tools from companies like InfoWise  (http://infowisesolutions.com/) or my preferred solution, Nintex Forms (http://nintex.com). There are two major reasons I prefer Nintex: it supports a development lifecycle, and it has full extensibility capability using JavaScript. It also allows me to create truly mobile forms, OK, there are 3 reasons I prefer Nintex.

Clients have a “Forms” project and immediately decide to start using InfoPath, in the belief that the tool can do what they need. Where clients get themselves into trouble is not fully understanding the requirements and jumping into developing an InfoPath form. What happens is the requirements grow over time, and with it the complexity of the form, which InfoPath is just not great at handling. The result is often a frustrated developer playing “whack-a-mole” with bugs in the form.

So before you start an InfoPath development project ask yourself a few questions:

• Do I have ALL the requirements
• Should this be one form or several joined by workflow or another form
• Do I need all the data elements available as SharePoint columns

Then consider the following:

• InfoPath Development is single threaded – you cannot have multiple developers working on a form at the same time
• InfoPath does not really support a development lifecycle, it is hard to move a form from a development system to test to production. It can be done but it is a tricky process
• The functionality available is largely hiding controls and a few date, time, string functions
• Conditional statements can be hard to build due to the dialog driven approach

So based on the needs of the form decide if InfoPath is the right tool for the job, or should you invest in an alternate technology.

If you do decide to start a new InfoPath development project, then here are a few tips to try and ease the process:

Sections

When building a form (as opposed to a SharePoint List Form) be sure to create logical sections in the form definition.  This allows you to find data easily within the form and provides convenient places to hang rules to hide groups of controls.

Data Connections

Try to use data connection files rather than directly linking to the data source – it makes it much easier to move the form from one environment to another.

Controls

Name your controls and buttons – it’s very hard in InfoPath to discover where rules have been attached – naming the buttons for example helps you find the functionality. A button marked button_57 is not very helpful, a button marked Save_Manager_Role is much better.

Consistent

Be consistent; whether that’s in naming conventions for data elements or controls – it makes it much easier to understand and find things.

Conditions

When creating conditions for hiding sections or controls on a form the logic can be a bit confusing. I find it easier to write the “display condition” and then try to invert it to get the “hide condition”. Name your rules and be sure that the name accurately reflects what it’s doing. Sometimes you will end up playing “whack-a-mole” with your conditions – you fix the condition for scenario B and then in testing you find you broke Scenario A. So you Fix A and break B – at this point stop and brute force the conditions – more rules is preferable to broken rules.

Validation

If you have validation rules for controls – generally I prefer that they run on the save button, rather than when the control values changes. The reason for this is the post backs and flashing that can occur can be frustrating for end users.

Views

Many times clients create a form for use by multiple roles, employee versus manager for example. They try to create one view to be used by all users. The rules become complex, because you are trying to hide different controls for different roles – read versus edit for example. Create different views for each role, it will simplify the rules and make it easier to maintain.

Hopefully these tips from the trenches will help you assess if InfoPath is the right tool, and if so help you avoid some common pitfalls.

-Ian