So you might know I’m a fan of InfoPath and think it is underused, but I also acknowledge that (as with most development tools) it has its limitations. There is only so much you can do with an InfoPath rule to make your forms more dynamic. There are third party products that provide additional rules, but even they fall short of integrating with your line of business systems. Most of the time your only option is to inject custom .NET code. This gives you good flexibility as a developer, but it could potentially require that the Web form be administrator approved and not run as a sandboxed solution. Perhaps a better approach is a service-oriented one.
We recently developed a form that required a button to lookup a customer ID and populate the customer’s address. In this case, a Web service already existed to return the address for valid customers. We added a rule to the lookup button to call the Web service and populate the address from the response. No development required, so the form can be published directly by the form designer.
Another example is for forms that have an email rule. A common requirement is to email a confirmation to the consumer who filled out the form and submitted it. InfoPath makes this easy by allowing you to add an email rule after the submit rule. However, if the mail server is down when the form is submitted, the form data will still be saved into a SharePoint library, but the consumer receives a non-descriptive error from the email rule. As a result, no confirmation email is sent and the consumer thinks the form data was lost, so they resubmit the form. A solution is to develop a Web service to check the state of the mail server, and condition the email rule based on a positive response from the Web service. If the email is not sent, then a property is set within the form to let the form owner know that a manual email needs to be sent later.
The only real caveat in all of this is that the InfoPath data connection that is associated with the Web service must be converted to a data connection file (udcx) and stored in a library on the SharePoint site. Is that a bad thing? Not really. It makes the administrator responsible for which Web services are allowed to be called from forms, and encourages portability for promoting forms from development to staging to production environments. There is a good walk through of connecting a form with a Web service in the MSDN Blogs. Consider making your forms more dynamic by taking this service-oriented approach.
