We started by marking the field as hidden by default in step 3. As a best practice, it always makes for a better user experience when hidden fields are revealed, as opposed to hiding visible fields on loading a record. In step 7 and step 8, we created the condition and rule to show the field; in step 9 and step 10, we created the converse condition and rule to hide the field. Always think about the reverse scenario when implementing business rules, otherwise, you will be faced with an irreversible action.

Given that the scope of the business rule was set to the default All Forms (top-right corner when editing the business rule), all forms will now respect that rule. If the scope was set to Entity, the rule would also trigger on the server side, which could be useful if implementing calculation rules that need to be respected when manipulating the data outside of a form (for example editable grids, bulk import, or through the Web API or SDK):

Behind the scenes, JavaScript functionality is created to address the rules' requirements. This is also respected in all form factors following the configure once, deploy everywhere design pattern.

Business Rules also have limitations, as follows:

• There is a limit of 10 If Else conditions per business rule
• Business Rules cannot control sections and tabs
• If not set to a scope of Entity, a Business Rule will only run on load and on changes to the field, not on save.
• Conditions cannot be a mixture of AND and OR; it's a set of one or the other

For additional limitations, visit https://technet.microsoft.com/en-us/library/dn531086.