Autocomplete Rule Variables

These are the common variable types used in an autocomplete rule, which closely align with the standard variable data types.

Variable	Usage
String	Define a specific regular expression (REGEX) pattern that you want to match a user-input text field to, such as phone number, address lines, name, and so on. Apply a transformation on a field that returns a string type value.
Integer	Define a counter to add to when controlling a looping logic. Store a number of days that you can use in the subsequent logic to add or subtract number of days from a date. Apply a transformation on a field that returns an integer type value.
Long Integer	Store IDs of any business entity such as job, position, salary basis, and so on. and subsequently assign them to their occurrence in a transaction business object like salary, assignment, position, and so on. You need to use a transformation function when setting up this variable.
Decimal	Store IDs of business entities such as job, collective agreement, salary basis in various descriptive flexfield segments. You can use Value Set queries on other objects when setting up customer specific associations between various entities. The transformation functions that return a decimal type value aren't available currently, unless you have a custom object function that returns a decimal type value.
Date	Store a date because of a calculation involving subtraction or addition of a specific number of days to another date. Apply a transformation on a field that returns a date type of value
Boolean	Set up a variable to control looping structures Break down a conditional validation to first evaluate the condition and set the Boolean variable, then, use the Boolean to validate with specific error messages depending on the failure conditions. Apply a transformation on a field that returns a Boolean type value.

Special Variables

Row and rowset variables are special variables that enable you to navigate through various object relationships to fetch the appropriate criteria for default or validating. Special variables allow you to navigate out of the current object to related objects to fetch the criteria. The starting point for your rule is the business object that contains the field that you want to default. For validation, the starting point can be the business object containing the fields you want to validate, but not always.

For field values in the current object, any changes made by the user are still in-flight without the transaction being submitted, similarly, any fields of related objects you fetch with these variables are also values "in-flight" and not yet submitted. For example, when you navigate from Salary to Worker Assignment, you get field values in the Worker Assignment object that correspond to values just entered in the preceding section. But these values won't be there in the Worker Assignment object prior to starting the current flow.

Here's what you can do using the special variables.

Fetch values in the fields prior to the current flow.
Compare and contrast old and new values to decide on default and validation rules.
Fetch value of fields that exist in the database, for objects that aren't part of the current flow. For example, if you navigate to Worker Assignment from the Change Salary flow, you will get values of fields in Worker Assignment that exist in the database. Another example is when you fetch values from an object that are lookup type entities only will fetch previously setup values of fields in the lookup.

Row Variable

You can use these variants of the row variable.

Variable	Usage
Row - Variant 1	Use row variable without Get First Row function when you expect a 1 to 1 relationship between the object you're operating on and the related object you're fetching on the right hand side, the options that allow for 1 to 1relationships of the lookup codes are shown.
Row - Variant 2	Use row variable with the function Get First Row when you expect a 1 to 1 relationship between the object you're operating on and a different object (such as a parent or a distinctly different functional area, or a parent object). For example, when you're traversing from Worker Assignment to Primary Work Relationship. Accordingly, when you define a row type variable, before clicking on the right hand side hyperlink, if you click on xyz to change to function, you can see the Get First Row function. Click the hyperlink to see related objects that can have a 1 to many relationship with the current object but of which you want the current applicable single row.

Variable

Usage

Row - Variant 1

Use row variable without Get First Row function when you expect a 1 to 1 relationship between the object you're operating on and the related object you're fetching on the right hand side, the options that allow for 1 to 1relationships of the lookup codes are shown.

Row - Variant 2

Use row variable with the function Get First Row when you expect a 1 to 1 relationship between the object you're operating on and a different object (such as a parent or a distinctly different functional area, or a parent object). For example, when you're traversing from Worker Assignment to Primary Work Relationship. Accordingly, when you define a row type variable, before clicking on the right hand side hyperlink, if you click on xyz to change to function, you can see the Get First Row function. Click the hyperlink to see related objects that can have a 1 to many relationship with the current object but of which you want the current applicable single row.

Rowset Variable

Use rowset variable when you expect a one to many relationship between the object you're operating on and the related object. For example, when you're traversing from the Person object to the Person Passport object or from the Person object to the Person Citizenship object, and you want to scan all possible rows. When you declare a rowset variable type, other functions aren't supported on such a variable (click the xyz icon to see this). But, when you click the hyperlink, it will again show the same related objects as in the second variant of row variable (with a Get First Row function). The difference is that you're setting up your rule to iterate over all rows of related object as opposed to just the current one

Person related objects are functionally compact, for example, email, phone number, name, and the business object that you start with is one of the child objects, for example Person Passport), while the criteria is in another child object (Person Citizenship). For a rule such as don't allow entry of passport prior to having a citizenship record for the same issuing country, you need to first define a row variable to traverse from the first child object (Person Passport) to the parent object (Person). You then define a rowset variable to go from the parent object (Person) to the other child object (Person Citizenship). Another example in the same pattern of rule is ensure email address must begin with person last name. In this rule, you need to define row variable with Get First Row to traverse from person email to person and then define another row variable with Get First Row to traverse from person to person name.