After working extensively on InfoPath forms for so many years, I would like to share some of the best practices or techniques which I always keep in mind while creating a system using InfoPath forms.
InfoPath offers great deal of features while designing user forms; however, if the features are not used in an appropriate manner, it might confuse the end users; hence, we need to take care of few things in order to make the form appealing and simple. Here is the list:
1) Hide the top ribbon and create buttons on the form for submission and close
I always prefer to have two buttons - one for Submit and the other one for Close - on an InfoPath form rather than using the options on top ribbon. In most of the cases, the top ribbon is not that visible to the users, and it takes some time for them to understand how to close or submit the form. In order to avoid this confusion, hide the top ribbon and create simple buttons on the form.
You can hide the following top ribbon from the form options.
2) Form must close automatically after the submission
We should always make sure that the form is closed automatically once it has been submitted. I have noticed many times that a new form opens once the form is submitted by the user. It is confusing and irritating; hence, we should always take care while designing the form that it is closed after a user submits it and goes back to the page where you want to redirect the user.
In case of big projects and client facing sites, the best approach is to create a button on a SharePoint page and place the link of the form on that button by customizing it by giving a source parameter.
For example: If I have created a survey form using InfoPath, I would prefer creating a page on a SharePoint site with required Web Parts for the data presentation with an appropriate button for the form's link. However, I will add a source parameter to the link, so that instead of taking the users back to the library, it should take them back to the current page. Appending the form's link with the source parameter, you can control the redirection aspect of the form.
3) Should consider the situations after a form is submitted
Whenever a form is submitted, the next step is to understand the possible situations of dealing with the submitted forms. InfoPath forms give you more flexibility in terms of controlling the behavior. For example, you can always set a functionality where the person who submitted the form will only be allowed to edit it and no one else which is not that straight forward to achieve in terms of aspx forms. There can be many scenarios:
a) Should we give the option for editing to the users?
b) Should the form be read only once it is submitted?
c) Other than the user, should any other person with higher authority should able to view the form?
We need to consider all the above situations and implement the functionality on the InfoPath forms accordingly. In case workflows are attached with the InfoPath form library, things are more difficult when it comes to implementing the functionality where we allow the users to update the forms later on.
4) Display proper messages for the validations
If a validation is true on any InfoPath form's field, it shows a red dotted line over that field; however, when you hover on that field, it displays the validation message. In all the scenarios, we should implement the functionality where the validation or error message is displayed below the field whenever any of the validations is true. In most of the situations, the user may not hover on the field; hence, without any message, they will not be able to understand the meaning of the red dotted line.
5) Limit the number of rules and validation
We should be very careful while writing the rules and validations for the form. Lot of rules and validations on a form can affect its performance and can make it slow. Every rule or validation triggers a post back event where a request to the server is made. In case, lot of requests are made at the same time to the server, the form may not show the expected behavior and might get crash.
Hence, we should try to implement only the most important and required rules & validations in order to normalize the form.
6) Limit the number of fields
In addition to the above point, we should also try to limit the number of fields on the form. The more the number of fields, the form will take more time to load; as a result, affecting the user's experience. Many times, I have heard people complaining regarding the inefficiency of InfoPath forms while loading. A simple fact: it is not always the fault of the software in terms of performance; a great deal of software's performance also depends on its implementation (apart from server's performance); hence, we should always strive to normalize the form in terms of rules, validations, and number of fields.
I hope you all enjoyed this article and learnt something from it. Thank you so much for spending your time and effort.
7) Uncheck "Automatically retrieve data when form is opened"
Always uncheck the above option while creating a data connection on the form. If you don t need to pull the data at the time of form load then it is a wise decision to uncheck the option and pull the data by creating queries and rules. At the time of form load, this option retrieves the entire data from the list or library where the data connection has been made; hence, it affects the performance of the form by unnecessarily pulling the data when you don t need it.
8) Follow proper naming conventions and documentation
Use proper naming conventions, especially in case of large and complex forms. In that case, it is very easy to manage the form in the long run. I always prefer to name fields on the form by separating the text by underscore. For example: In case I need to name a field for Employee Name, I write the name of the field or control as "Employee_Name".
Also, use proper documentation for the rules and validations on the form. We do have a "Rule inspector" option to check all the rules and validations on the form; however, nothing can beat a proper documentation as it is very helpful in maintaining the complex and large forms.
9) Use coding as the last option
We can achieve a lot by writing rules and validations; hence, coding should be preferred as a last option. If we need to achieve something complex which cannot be done using rules then we should go with the coding option as the rules are always executed first and then the code.