Partager via

Do it anyway: Submitting with Data Validation errors

  • Article

When building a workflow solution using InfoPath, it is often necessary to enforce data validation for some, but not all users. For example, in a simple expense report workflow, Employee->Manager->Accounting, the manager may be required to specify the cost category. The employee, however, can't provide this data. This means that setting the "cannot be blank" property for the costCategory field in the InfoPath form will not be enough to make this work. In this article, we will explore a technique that will let you use powerful InfoPath data validation capabilities to enforce this business logic correctly.

 

You may have seen a different incarnation of the same problem - "if only I could submit the form with data validation errors...". If so, read on.

 

  1. Create a node in your data source that remembers the role of the current user; let’s call that node userRole. Create rules or code to get that node populated on load of the form.

    Trick 1 - acquiring user role. To set the value of a node to the current user role in rules, use the XPath expression xdXDocument:get-Role() .

    Trick 2 - acquiring Active Directory username. If you are using InfoPath 2007, you can get to the username of the current user through the built-in userName function. In InfoPath 2003, the easiest way to accomplish this is to write a simple whoAmI web service (here is a sample implementation), and plug it in to your form template through a secondary data connection.

  2. Setup data validation logic on the costCategory field by using the Data Validation dialog (not through the “cannot be blank” shortcut in the properties dialog).

  3. Add a new "logical and” clause to the data validation condition. This clause will check if the userRole actually requires the field to be filled out. The entire data validation condition will evaluate to false if the userRole doesn't have this requirement, and the error message will not be shown:

 

This technique will work in both InfoPath 2003 and InfoPath 2007, and it is supported in browser-enabled form templates.

 

Alex Weinstein

Program Manager

Comments

  • Anonymous
    October 09, 2006
    Surely the simpler solution is to just clear the errors object according to the user or role?

  • Anonymous
    October 10, 2006
    Clearing the Errors collection presents a converse problem: you'd need to verify that everything that's necessary for this user to fill out is, in fact, filled out - and if so, clear the Errors collection. This means writing every data validation expression in code, which may or may not be harder, depending on the scenario.

  • Alex

  • Anonymous
    October 15, 2006
    Fair point, but in my case I actually disable validation completely for certain users (or if they press the hold button). So the Errors.Clear() function works really well for me. :-) by the way, thanks for the posts to my blog. cheers Bruce

  • Anonymous
    October 16, 2006
    Bruce, this makes sense. Clearning the Errors collection then seems like a perfect fit for your scenario. One thing to remember, though - don't forget that the Errors collection is not persisted. This means that if a customer who's not supposed to see any errors saves the form and then loads it back may see the validation messages again! To go around this issue, place your validation-disabling logic into the onLoad code, too. Cheers!

  • Alex