How You Determine the Rule Type

The rule type determines which runtime event the autocomplete rule will trigger for.

These are the different rule types:

• Business Object Default: This triggers when the selected business object is created by the application, which is when the user enters the section or clicks the Add button

• Business Object Validation: This triggers when the selected business object is saved by the application, which is when the user clicks the Continue, Submit, or Save and Close buttons.

• Business Object Field Validation: This triggers when a field of a given business object enters the ADF validation cycle, which is when the user tabs out of a field.

• Business Object Field Modification: This triggers after the field of a given business object completes the field validation event.

The classification of the technical events listed earlier also apply to HCM Data Loader, which deals with creating, updating, and saving business objects in a certain sequence. Hence, it's easier to understand when a rule takes effect, but, in the UI, the relationship between the UI and the data model is complex, which makes it difficult to determine the exact timing of these technical events.

In order to simplify the understanding of these technical events and determine exactly when a given rule triggers especially in the UI, these four events can be functionally characterized in these ways.

Event	Rule Type
Enter a section	Business Object Defaulting
Exit a section	Business Object Validation
Tab out of a field inside a section (validate)	Business Object Field Validation
Tab out of a field inside a section (default)	Business Object Field Modification

Entering a Section

In most cases, a business object is created when you first enter a section. The business object defaulting rule is triggered when you first enter a section. For example, the Worker Assignment object is created when you enter a section and the Salary object is created when you enter the Salary section.

These are the exceptions to this rule.

• Multiple objects are saved when exiting a section, hence, the Object Validation rule triggers for all objects.

• More than one row of a single business object are modified and saved, hence, the Object Validation rule triggers for each row of the business object. For example, when converting a pending worker, Work Assignment record of type pending worker is updated and a Work Assignment record of the converted type - contingent worker, nonworker, or employee, is created. Hence, an Object Validation rule triggers twice, once for each row that's updated and saved.

What You Can Do	What You Can't Do
You can code the default to always be of some value. For example, Assignment Category = "Regular" or based on some artifact that's already known to the runtime application at the time of object creation (or entering a section). These could be values in the previous section or values in the key organization level setup objects such as legal employer.	You can't use a field that's later in the section or in a subsequent section as a criterion for defaulting value.
N/A	You can't validate and consequently show either an error or a warning message.
N/A	Certain business objects won't support this type of rule, either for specific actions or across all actions.

Best Practices:

• Ensure the default values are valid.

• Don't use a defaulting rule type to show error messages.

Exiting a Section

In most cases, a business object is saved when you exit a section. The business object validation rule is triggered when you exit a section after clicking the Continue button or the Submit button (without clicking the Continue button). For example, the Worker Assignment object is saved when you exit the Assignment section.

Some exceptions to this rule are If multiple objects are saved when exiting a section, then Object Validation rule of all objects will be triggered. Further, if more than one row of a single business object are modified and saved, Object Validation rule will be triggered for each row of the business object. For example, when converting a pending worker, Work Assignment record of type pending worker is updated as well as a Work Assignment record of the converted type, Contingent, Non-worker, Employee, is created. Hence, an Object Validation rule will trigger twice, once for each row that's updated and saved.

This type of rule triggers on every row that's saved. This is an important consideration when date-effective splits occurs because of your transaction. Not only, is the new row saved but also an existing row is modified or saved due to the nature of the transaction. You have to apply additional conditions if you want your validation only to trigger on the new row. Sometimes, these additional conditions aren't necessary as the existing rows already comply with your validation rule.

What You Can Do	What You Can't Do
This rule type is preferred over business object field validation because all fields relevant to the validation rule can be used in the sample without assuming the field in which the user entered an incorrect value. Let's say you create a rule that if Assignment Category is Regular then Hourly/Salaried field value must be Salaried. In this case, though Assignment Category field comes before Hourly or Salaried field in the UI, you can't assume that the user will enter the values in the same order. Even if they enter the values in the expected sequence, you can't conclude the field in which the user entered an incorrect value. Hence, there's ambiguity over whether Assignment Category must be changed to Temporary and leave the Hourly/Salaried as Hourly or the other way around. A business object validation rule enables you to enter both values, and displays an error on incompatibility.	The criteria for validation may not be a field that's part of a section not yet navigated to. Hence, you can't add warning messages in this type of rule.
This rule type allows the user to decide which validation to fix. While it's an ideal user experience to trigger a validation as soon as the user exits a field, considering the point mentioned earlier, it's recommended to use Object Validation rule type instead. Sections in responsive pages are more compact and often the delayed display of the error message (on Continue, instead of field tab-out) is acceptable while allowing the user to remain within the section to fix errors.	If the criteria for the validation rule is in a section prior to the current section, then it's expected that user fixes the value of the field in the current section to comply with the validation rule before going back and editing the value in the field in the previous section.
The criteria for validation can be any field on the current section, a field in the previous section, or a previously setup object related to the current object. During object validation, even if a field in the section isn't mapped to a column in a table, yet all fields from the pages are transferred to the object and hence the object validation rule will be able to use these values in the rule.	The responsive pages won't allow the user to go back and edit previous section if a validation error on the current section is displayed. Once a default has occurred based on a value of a field in a previous section, if you go back and edit the criteria field, the default won't re-occur when entering the section containing the field that was defaulted the first time around.
N/A	You can't default values in fields in this type of rule. There are some exceptions to this rule. Default values into another field during object validation will call the field validation cycle of that field with no provision for user interaction resulting from errors, if any, during the field validation.

Best Practice:

• Don't use this rule type for specifying default values.

Inside a Section

There are 2 potential events that can execute when the user is within a section in the responsive pages, business object field validation and business object field modification, in sequence.

Tabbing Out (Validation)

The business object field validation rule is triggered first when the user tabs-out of a field.

What You Can Do	What You Can't Do
You can base the criteria for validation on any field that's already accessed by the user in the current or the previous sections, or any field that has already been setup as part of Workforce Structures setup.	If the field is transient and is only on the UI, but not in the model layer, then it isn't possible to execute this type of rule.
You can sample old and new values of the current field on which the validation rule is written. For numeric fields, this can be of help with percentage change calculations.	You can't default values into any fields, and can't warn users about errors in this type of rule.
N/A	If the user doesn't change the value in the field, this rule won't trigger.

Best Practice:

• Don't use this rule type for specifying default values.

Tabbing Out (Default)

The business object field modification rule type will trigger after the business object field validation rule when the user tabs out of a field

What You Can Do	What You Can't Do
You can default a value in another field in the same section based on the value entered in the current field.	If the field is transient and only in the UI but not in the model layer, then it won't be possible to execute this type of rule.
Show a warning after the user enters a value in the current field. The warning message can be dismissed by clicking the OK button, and if the value in the current field doesn't change, the warning message won't re-appear.	You can't show an error message in this type of rule.

Best Practice:

• Ensure the default values are valid.