1. Configuring and Extending HCM Using Autocomplete Rules
  2. How You Create a Rule in Autocomplete

How You Create a Rule in Autocomplete

Creating an autocomplete rule involves these steps:

  1. Declaring any variables you want to use with or without any transformations, using built-in functions (these are equivalent to some parameters of Transaction Design Studio).

  2. Using the IF condition block, which enables you to achieve one of the possible outcomes: Default, Show Error, Show Warning.

The rule logic is best derived by writing down the steps for execution of the rule. For field level rules, after finalizing the object and the rule type, you also specify the field name on which you want this rule to trigger.

Rule Variables

You have access to all fields inside the current object along with attributes of various lookup fields on the current object and related to but completely separate (typically parent or child) objects. For example, when working with Worker Assignment business object, you have access to all these:

  • Fields on the assignment

  • All attributes of lookup fields such as job, grade, business unit, and legal employer

  • Related parent business objects like Work Relationship

  • Related child business objects like Work Measure

While the field you're defaulting or validating has to be a part of the current object, the criteria can be on the current business object, on lookups or on related objects. If the field is on the current object, you don't have to do anything to the sample values.

You need to use variables for these reasons:

  • Related Objects: In order to sample values of fields in other related objects, lookup or parent or child type, you need to declare a special variable to get access. If you want to sample values of just fields in the current object or related objects, after declaring access to related object, you need not further declare a variable to contain the value of a field in those objects. In addition, the objects that you access can give you further access to other related objects.

  • Transformations: Let's say you want to apply some transformations such as sub string, begins with, or year of on the value in a field, the current object, or on a related object. You need to define variables to apply the necessary transformation to have them ready to use in your final condition logic. The transformations are made available as a series of functions that you can apply on various fields and store the result in these optional variables.

  • UI State or Application Variables: You want access to special UI context, for example, which flow you're in or what's the legislation code. You want access to the application context such as what's the role of the logged in user or has a given field been modified. These are again available as transformation functions.

Rule Criteria

You don't have to do anything special to get access to a field on the current object. However, when trying to get access to a related object, it's useful to refer to the following data model navigation diagram. You can use different combinations and number of fields from other objects.

data model diagram

You need to do these actions to get access to a related object

  • Start with any business object and follow the directions of arrows to understand what you have access to.

  • Determine the steps to reach a given related object. For example, if you want to default salary basis based on the job FLSA status using the Salary business object, you need a variable to get access to Assignment from Salary. Then you need access to Job (a Workforce Structure setup object). From the job, you can then get access to the predefined job extensible flexfields containing the FLSA status.

  • Bypass a business object in some cases. For example, assignment > position > job versus assignment > job.

Limitations

You may encounter these limitations when executing your rule

  • You want to execute a validation when the user enters a section, for example, don't allow termination if employee is on leave of absence. You have to rewrite this rule because it isn't feasible to execute with the available rule types. You have to rewrite the rule as a Field Validation rule on the first mandatory field in the section, which is your earliest opportunity to trigger a validation rule. If a particular field doesn't support Field Validation rule, then your earliest opportunity is only on exit of the section.

  • You want to validate a field, immediately on tab-out but the criteria for the tab out is a field, which the user hasn't encountered so far. You have to rewrite your rule as an Object Validation rule that enables you to check for values in all fields

  • You want to warn users when they leave a section. There's no rule that supports display of warning messages just when exiting a section. The earliest opportunity is the last mandatory field on a given section and write a Field Modification rule if supported by the rule.

In addition to the above basic limitations, other restrictions only apply to certain objects. While an object has to be created, updated and saved by the application, the timing and nature of these events varies between actions. For example, during termination, the Worker Work Relationship object doesn't get created. Hence, a business object defaulting rule won't work here. Further, for any of the given objects, these additional restrictions can apply across all actions, only for specific actions, or for specific fields.

For more information on exceptions for business objects, refer to the Business Objects in Autocomplete chapter.