What are the steps for designing an autocomplete rule?

Hello, my name is Steve. In this video, I’ll explain the steps for designing an Autocomplete Rule.

After you’ve analyzed the requirements of your use case, you can then start designing your rule. There are three steps in designing an autocomplete rule. The first is to identify the business object for the rule. This also includes identifying the specific section for the action that triggers the rule.

The next step is to identify the type of rule you want to trigger. There are four rule types. We’ll look at these in more detail in a few minutes. As your use case goes through the approval process, Oracle recommends the business object and rule type you’ll need to meet your requirements.

Finally, you author the logic of the rule. This includes defining the variables to capture criteria for the rule, and then writing the logic that will determine the outcome of the rule.

The first step in designing an autocomplete rule is to identify the business object. This includes:

• Identifying the section that contains the fields you want to default or validate. For example, if you want to validate the date of a promotion or transfer, then you would look at the date field in the When and Why section. This is the field that specifies when the promotion or transfer will take place.

• Identifying one or multiple actions to which the rule will apply.

• A business object has a strong correlation with a specific section in an action.

• Sometimes a section has the same name and business object no matter what action they are a part of. For example, the When and Why and Salary sections. These sections each have the same names across all actions in which they appear. And they call the business objects with the same names: The When and Why business object, and the Salary business object.

• Other times the section name may change depending on the action. For example, the Employment Details, Promotion, Transfer, and Working Hours sections all call the Worker Assignment business object. If you create a rule for the business object supporting these sections, it will trigger in all of the actions that call that business object.

• Use an HCM Parameter in a rule condition statement, to only trigger the rule in certain actions. It is important to identify the actions the rule applies to. By identifying the actions, you may learn that the rule type you want to use may not be feasible.

It’s not always obvious to pick out the business object you would use to meet the purpose of your rule. For example, in the Addresses section of the Add a Contingent Worker flow, if you want to validate the format of the address field you would use the Address business object. But for the same action and section, the Address Type is from the Person Address business object. For the same action, if you want to validate the email format in the Communication Info section, you would write your rule using the Person Email business object. And to Validate the phone number, you would write a rule based on the Person Phone business object. The autocomplete rules documentation contains a complete list that maps actions and sections to their related business objects.

Use cases submitted in the Autocomplete Program application will display the applicable business object to use upon approval. This makes it important to submit use cases because it’s not always obvious to pick out the business object you would use to meet the purpose of your rule.

Next, you need to identify the type of rule you need to meet your purposes. There are four types of autocomplete rules:

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

• A Business Object Validation rule 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.

• A Field Validation rule triggers when a field of a given business object enters the ADF validation cycle, which is when the user tabs out of a field.

• A Field Modification rule also triggers after the user tabs out of a field. But it occurs after the completion of the field ADF validation.

It's important to understand these rule types and how they function. It should help you understand the events and the timing which trigger the different rules. When you Enter a section you can default values. When you exit a section you can validate values. When you tab out of a field, you can validate and default values.

In most cases, a business object is created when you first enter a section. For example, a Salary object is created when you enter the Salary section.

When defaulting a value upon entering a section, you can specify the defaulted value. For example, set Assignment Category to be “Regular”.

There are also limitations. One limitation is that you can’t use a field that appears later in the section, or in a subsequent section, as a criterion. You can only use fields that have already been visited as a criterion for the rule.

You can’t show an error or warning message, since you can’t validate after defaulting. This type of rule is not supported by certain business objects.

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 or Submit button. This rule is preferred to field validation because all fields relevant to the validation rule can be used as criteria to determine if an error has been made. In field validation, you cannot be sure a user has entered values required for criteria.

The criteria for validation can be any field in the current section, a field in a previous section, or an object previously set up. You cannot use fields as criteria from a section not yet navigated to. Therefore, you can’t display a warning message in this type of rule. If a value in a previous section needs to be changed, the field in the current section needs to be fixed before returning to the previous one. Otherwise, the error message will keep appearing.

The business object field validation rule is triggered first when the user tabs-out of a field. You can base the criteria for validation on any field that's already been 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. You can retrieve old and new values of a field.

The things that you can’t do include:

• Default values.

• Or show a warning.

• Also, If the user doesn't change the value in the field, this rule won't trigger.

• Certain fields in the UI are transient, which means they exist only in the UI and not in the data model. This rule won’t work for those fields. Transient fields are listed in the documentation.

The business object field modification is also triggered when you tab out of a field. This rule triggers after any application validation rules. This rule allows you to default a value in another field in the current section. You can display warning message after the user tabs out of the field. Once the user clicks OK to close the message, it doesn’t appear again. You can’t show an error message with this rule type. And similar to a Field Validation rule, this rule won’t work for transient fields.

Declare any variables you want to use using built-in functions. You should not define variables to store the values of a field. You can access the values of the fields directly through the object.

Use the IF condition block, which enables you to achieve one of the possible outcomes: default a value, show an error message, or show a warning message. Of course, another outcome is that nothing happens because the criteria in the rule isn’t met.

This concludes the explanation of the steps for designing an autocomplete rule.

Thanks for watching.