Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

Best Practices for Rules

Best Practices for Rules

Rate This
  • Comments 2
My forms have a bad habit of accumulating more and more rules as I add more and more functionality over time, so I came up with a set of guidelines to keep those rules clean and orderly.
 
 
Remember that there are four places to add rules
  1. On Button Click (in Properties dialog)
  2. When values change (in Controls and Data Source Properties)
  3. On Submit (in Submitting Forms dialog)
  4. On Load (in Form Options | Open and Save section)
 
Give your rules names for the scenario they capture
Good names will summarize their conditions/actions in a more friendly way: eg "Submit using multiple data connections", or "Cancel query if expenses too high".
 
Group rules by condition, but separate actions without conditions
If more than one action has the same condition, put them together so you can edit the condition only once. Otherwise, put each action in its own rule, so you can easily reorder them independently.
 
Use "Stop processing rules" to save retyping conditions
If there's a case where you don't want to run any of your rules, add a rule that checks that case. It doesn't need to have any actions, just check the box to stop processing rules and put the rule before any of the other rules that would also check that case. For example, if you want to skip some submit logic if the expenses in the form are less than 100, put that condition in its own rule before your submit logic, and just have it stop the rules.
 
Use dialog messages to debug while developing
Dialog messages are great for tracing your rules at runtime, but are usually jarring while filling out the form. If you have a condition message to show, use conditional formatting instead to hide/show a section/expression-box with the message. You can even make the message dynamic by having the expression box look up a value in the data source and setting that value from the rule.
 
Know when to use calculated default values vs set a field's value
The “Set a field’s value” action is best for values that only need to be set/copied once, or for values that are conditional. For values that need to update every time another field changes unconditionally, best to use a calculated default value. Good examples for rules:
  • Demo button that populates an entire form with sample data
  • Copying suggested values from a secondary data source that the users can edit afterward
  • Setting someone’s email address based on their name, but only if the email field is blank beforehand
 
Got tips?
If you've got your own best practices we'd love to hear them! Post a comment to share your insights with the whole community.
 
- Ned
Leave a Comment
  • Please add 4 and 7 and type the answer here:
  • Post
  • working with 2007 right now, not sure if this is currently available but it would make rules a million times easier to be able to preview a template form, fill out the data you want and record all of the controls current states and then use them as a rule for a specific control instead of having to set values for every other control in the form. ex (when drop down box field "pepperoni pizza" is selected use recorded controls to auto populate check boxes for "pepperoni" "cheese" etc. etc.)

  • Is there a way to set a rule (Action, Formatting, etc) for an entire section? Example, make all fields required within a section.

Page 1 of 1 (2 items)