Autocomplete Rules 1

Autocomplete Rules
Oracle Human Capital Management
November, 2020 | Version [1.01]

Copyright © 2020, Oracle and/or its affiliates
Public
DISCLAIMER
This document in any form, software or printed matter, contains proprietary information that is the exclusive property
of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle
software license and service agreement, which has been executed and with which you agree to comply. This document
and information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle
without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated
into any contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation
and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and
should not be relied upon in making purchasing decisions. The development, release, and timing of any features or
functionality described in this document remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this
document without risking significant destabilization of the code.
Note: In the images or examples included in this document regarding: user details, company names, addresses, emails,
and/or telephone numbers represent a fictitious sample of data (based upon made up data used in a demo
environment). Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.
2 Autocomplete Rules | Version [1.01]

Copyright © 2020, Oracle and/or its affiliates | Public
TABLE OF CONTENTS
Disclaimer 2
Introduction 5
What’s the Autocomplete Rules Tool? 5
Application vs. Autocomplete Defaulting and Validation 7
What can I do in Autocomplete ? 9
Analyze the Requirement 9
Parse the Requirement 9
Understand the Elements of a Requirement 9
3 Steps in Designing a Rule 11

Identify Object 12
Region where the fields are located 12
Action to which the rule applies 12
Identify Rule Type 12
Enter Region 13
Exit Region 13
Inside Region 15
Limitations of Autocomplete Rules 16
Author Rule Logic 17
Anatomy of a Rule 17
Variables 18
Criteria 18
Working with the Editor 19

Enable a Sandbox 19
Navigation Elements 19
Down Arrow 20
xyz 21
Hyperlink 22
Variables and Functions 23
Common Variables 23
Special Variables 23
Data Type Dependent Functions 27
Default Statement 28
Show Error 28
Show Warning 29
Row Collection Looping Block 30
Troubleshooting Issues 31
Object-based Rule 31
Validation Rule 31
Field-level Rule 31
Criteria 32
hcmParams 32
Page Properties 32
Type of Errors 32
Test Event 33
Test Using Display Variables 34
Assignment as Criteria 34
Advanced Debugger 34
Object Functions 38
Need for Object Functions 38
How You Create and Initiate Object Functions 39
Auto submit and Partial Page Refresh 45

Auto Submit 45
Partial Page Refresh (PPR) 50
Old and New State of Fields 51

INTRODUCTION
Oracle delivers a Human Capital Management (HCM) suite of products that cater from small and medium scale
businesses operating locally, to large multi-national businesses operating worldwide. The HCM application suite has
several configurable and optional components to tailor the suite to customers’ specific needs. Autocomplete Rules is
part of the HCM Experience Design Studio like the Transaction Design Studio (TDS). With the TDS, Oracle delivered a
capability to tailor the user experience in terms of fields and regions to show, hide, or mandate.
Autocomplete Rules takes the user experience to the next level by enabling customers to define specific criteria for
different kinds of defaulting and validation. The need for customer-specific default and validation arises from two facts.
Firstly, the underlying data model that supports our applications is the same for all customers. Secondly, every business
is unique and has its own requirements to enforce rules governing their implementation of Oracle HCM suite of
applications. With Autocomplete Rules, you can automatically populate fields while at the same time take advantage of
Oracle-delivered reporting and integration capabilities by utilizing the capabilities of the single data model.
WHAT’S THE AUTOCOMPLETE RULES TOOL?
Autocomplete = Autopopulate (Default) + Autocorrect (Validate)
The 2 key, more commonly used words - default and validate form the corner stone of Autocomplete Rules.
Autocomplete Rules is different from autocomplete used in list of values (LOV), which is more of a search-as-you-type
paradigm on most LOVs.

The defaulting or validation requirements can be driven by business process, localization, company policy, or statutory
requirements. The implementation is driven by rules authored in a logical scripting environment that can be tailored to
suit a wide range of conditions.
Autocomplete Rules is a Data Model Layer Extensibility framework unlike the TDS or Page Composer, which are both UI
driven. The tool doesn’t recognize any UI and is driven by the state of values in various fields of different objects. There
is a provision for an asynchronous, one-way communication by the UI to Autocomplete Rules to allow for better control
of the timing of execution of a desired default or validation rule. Autocomplete Rules leverages the advantages of the
Data Model Layer Extensibility framework that allows for an endless possibility of criteria to default or validate, typically
anywhere in the guided process flow or any static setup data.

The rule authoring is done using a Guided Logical Coding or scripting. Autocomplete Rules then generates a more
complex code for the Applications Data Framework (ADF) Business Objects Editor framework to interpret and execute
the rules. The performance and behavior of a custom rule is same as an out-of-the-box Oracle delivered the rule
APPLICATION VS. AUTOCOMPLETE DEFAULTING AND VALIDATION

When there is a conflict between predefined application defaults and validation rules and Autocomplete Rules, these
guidelines apply.
Default
 If data is defaulted out-of-the-box, Autocomplete Rules can’t override the application defaults.
Validate
 All rules from the application and Autocomplete Rules are triggered.
 Transaction must be validated by the application and Autocomplete Rules to be completed.
 All warning and error messages from the application and Autocomplete Rules are displayed.
Example of Error Message from Autocomplete Rules

Example of Validation from Application and Autocomplete Rules

WHAT CAN I DO IN AUTOCOMPLETE ?
You can default and validate data using Autocomplete Rules.
Default
Autocomplete allows for custom defaulting of various fields, even if they aren’t actually visible to end users. The criteria
maybe values in other fields in the same region, either visible or hidden, or values in fields in previous regions just
entered by the user. These values may still be in-flight, as the transaction hasn’t been submitted yet, or could be static
values such as the previous state of assignment prior to affecting the current change. The criteria fields could be any of
the commonly used Workforce Structure Setup objects, seeded or extensible flexfields. The defaulted value appears as
an automatically filled out value based on your specific rule in the user interface.
Validate
Validation rules can leverage the extensive criteria available that are relevant to the current context. The result of a
validation can be a warning message before proceeding or could be a hard-stop error. These messages will appear in
the same window along with the out-of-the-box error messages.
WHERE DO I START IN AUTOCOMPLETE ?
Analyze the Requirement

In this section, you will learn to analyze, parse, and break down a requirement to determine its feasibility. Not every
requirement that contain words or phrases such as, ensure, default, validate, prevent, don't allow, or synchronize is
possible to achieve using Autocomplete Rules. After analyzing the requirement, you will be able to conclude whether the
requirement is feasible or not, or whether you can achieve the requirement sub-optimally.
Parse the Requirement

To parse a requirement, highlight specific words in the requirement that must be coded and determine the sample
values in various fields of the object. You can also think about the user interface where you want to see the effect of the
default or validation rule (this isn’t explicitly specified in the requirement). Also, you can consider some implicit criteria
such as “only for a given user role”. These implicit requirements are used mostly in validations than in defaulting.
Let’s look at a couple of examples.
Example 1
Allow transfers only on the 1st or 16th of a future month for US employees and no transfers in November and
December.
This answers the question - what date am I validating?
Example 2
Employees on leave of absence can’t be terminated

This answers the questions - what fields am I validating? and what’s the criteria? User experience?
Understand the Elements of a Requirement

Before considering Autocomplete Rules for any defaulting data or validation requirement, you need to look at the
existing functionality. This can be – out-of-the-box delivered defaults or validations. In some cases, if a given field is
defaulted out-of-the-box, Autocomplete Rules is unable to override the default with a customer-specific rule-based
value.
The first part of the requirement requires you to identify the fields that needs to be defaulted or validated. Here, you
need to be cautious because the same field can be a part of different actions. It’s important to identify the section that
contains the field. For example, if you want to validate the Assignment Effective Date, then most likely, you may want
the validation to trigger when the user is in the When and Why section of the Promote or Transfer flows where they
need to enter the Promotion Date or the Transfer Date respectively.

If you can’t identify the fields, note the section where you would like to see the effect of the rule. If you can’t identify the
region either, then it may not be feasible to implement such a rule in Autocomplete Rules. For example, “Don't Allow
Withdrawal of Termination” rule implementation may not be possible because Reverse Termination is a button on a
page and doesn’t involve any field or region.
You may not be able to use Autocomplete Rules for defaulting or validating for these reasons.
 A field isn’t visible or editable, either out-of-the-box or made visible using the TDS.
 Values in fields may not be available in Autocomplete Rules because of timing, even though they are
synchronized across different regions in a responsive user interface.
 Several fields that are shown in the Autocomplete Rules UI are reserved for application use only. For example,
Object Version Number and Update by User.
The second part of the requirement is to focus on the user experience. This is critical not just for designing and building
the rule but to even determine feasibility. Autocomplete Rules may be able to execute a specified validation, but the
validation will only trigger when the transaction is submitted and won’t allow the user to go back and edit. For example,
to determine the user experience, you need to keep the guided process flow in the responsive UIs in mind. You need to
ask questions on the kind of user experience you want - The answer to your user experience question - when the
validation should be triggered? - should be one of these.
 When entering a region
 When tabbing-out of fields
 When exiting a region
 On submit
This step will decide the rule type to use and the execution of the rule. After understanding the nature of operation of
the data model elements vis-à-vis the UI, you may have to change your requirement to something sub-optimal, yet
acceptable.
The third part in the requirement analysis is to list out all the criteria for defaulting or validating a field. Some of these
criteria may be around the current fields to be defaulted or validated while others may be in regions that the user has
already crossed in the flow or some predetermined setup data. Here, you need to focus on whether the criteria is known
or is something that is yet to occur in the responsive flows.
Autocomplete Rules checks the recent past state prior to the changes in the current flow and the static setup data. It
can’t determine the previous state of elements (fields) in the regions yet to come, although with some exceptions.
As a general principle, you must never use a field as criteria that isn’t visible and editable in the responsive pages,
out-of-the- box or through the TDS. For example, when you’re working with Worker Assignment, if you want to check
the action code, don’t use the action code on Assignment but instead use the action code on Action Occurrences, which
drives the When and Why region where the action is both visible and editable. HCM applications will synchronize
values within and across regions, as you progress through the responsive pages. But the timing of availability of
values in these fields cannot be guaranteed unless they are visible and editable by the user in the responsive
pages. In addition, several fields that are shown by the Autocomplete UI are reserved for application use only.
It’s useful to break down the requirement in a tabular format like this.
RULE WHAT WHERE WHEN CRITERIA
Functional Default (D) fields or Actions where the When is the rule List all criteria (product
Description of the Validate (V) fields defaulting or expected to be and field) implied in the
Rule with error or warning validations should be triggered. Values are rule to default or
message shown Enter regions or validate fields
page (D)
Continue or Submit
(V)
Tab out field (D or V)

If the worker is full Validation – error  New Hire - Continue or Submit  Employment –
time employee, message Employment Assignment
working hours  Change  Category = Full
shouldn’t be less Assignment - time or Part time
than 40 hrs. Employment  Employment –
Working Hours
Warn users that Validation – warning Termination – When Action Reason – Tab  Action Reason
during termination message and Why out field  Termination
selecting certain Reason
action reasons
prevents employees
from being rehired.
Salary basis is Default  New Hire – Salary Enter region or page  Compensation –
defaulted based on  Change Salary - Salary basis
the Job FLSA status. Salary  Employment – Job
FLSA status
In the Add Default Add Contingent Job tab out field  Employment – Job
Contingent Worker Worker - Employment  Employment –
flow, when the user Assignment
selects the job BAA, Category
default these fields  Employment –
Working Hours
 Assignment
 Employment –
Category = Full
Frequency
time temporary
 Employment –
 Working Hours =
Hourly paid or
80
Salaried
 Frequency =
Biweekly
 Hourly Paid or
Salaried =
Hourly
You can complete the feasibility assessment after following the 3 Steps in Designing a Rule (next section). You don't
have to actually build the rule but need to identify all the parts to be able to determine feasibility. If the 3 steps lead you
to restrictions or in-feasibility, then you need to come back to this section and alter the requirement and analyze the
requirement and subsequently go through the 3 steps again to determine feasibility.
3 STEPS IN DESIGNING A RULE
When you design a rule in Autocomplete Rules, you need to follow these steps.

Identify Object
Region where the fields are located

Unlike the TDS, where the rule is specific to an action (or flow), Autocomplete Rules is a data model driven extensible
framework that starts with a business object. Typically, a business object is a logical representation of a table with some
columns and rows, and can be initiated at various places in a responsive UI. It has a strong correlation to a specific
region in an action. The region in any responsive UI typically operates one object at a time (there are exceptions).
Sometimes, regions have the same name (and therefore operate on the same business object) regardless of the action
that they are a part of, for example, When and Why, or, Salary.
Regions can be named differently according to the action but the underlying object that these differently named regions
use is the same. For example, Assignment Details, Employment Details, Promote, Transfer, Working Hours - all call the
same underlying business object. So if a rule is written on an object, supporting these regions, the rule will trigger
regardless of the action it is a part of. If you want the rule to be triggered for a specific action only, you need to explicitly
state this in the rule using an inclusive or exclusive condition,
The first step is to identify the object and to do so, you need to identify the region that contains the fields that you are
defaulting or validating. After you identify the region, refer to the Region to Object Mapping white paper to determine
the business object you need to start with.
Action to which the rule applies

The same business object can be operational in different actions. So while the action doesn’t determine the name of the
business object, it’s a good practice to note down the actions the rule applies to. Since the nature of operation on an
object can vary between actions, this implies that for certain actions the type of rule you envisioned may not be feasible
or needs to be rewritten.
Identify Rule Type

The rule type essentially determines the runtime event at which a give rule on a given object attempts to trigger. The
four key events that are allowed in Autocomplete Rules are -

 Object Defaulting: This rule triggers when the selected business object is created by the application that is when
the user enters the region or clicks the Add button.
 Object Validation: This rule triggers when the selected business object is saved by the application, that is when
the user clicks either the Continue, Submit, or Save and Close buttons.
 Field Validation: This rule triggers when a field of a given business object enters the ADF validation cycle, that is
when the user tabs out of a field.
 Field Modification: This rule triggers after the field of a given business object competes with Field Validation
rule type.
To simplify these events and determine exactly when a rule triggers, these four events can be functionally characterized
in the following four ways:
Enter Region
When you first enter a region, a business object is created. The business object defaulting rule is triggered when a user
first enters a region. For example, the Worker Assignment object is created when you enter a region or the Salary object
is created when you enter the Salary region.
Though there are a few exceptions to this functional rule (objects gets created when you enter a region), one notable
exception is when after entering a region, there are no fields displayed until the user clicks the Add button inside the
region. Examples of this are in the Line Manager region; the Work Assignment Supervisor Object gets created only when
you click the Add button inside the region.
What can you do in the type of rule?
During this event, you can either "hard-code" the default to always be of some value, for example, Assignment Category
= "Regular" or based on some artifact that is already known to runtime application at the time of object creation (or
entering a region). These could be values in the previous region or values in key organization level setup objects such as
Legal Employer.
What can you NOT do in the type of rule?
You can’t use a criteria for defaulting a value in a field that is later in the region or in a subsequent region. In this rule
type, you can’t validate and consequently show either an error or a warning message.
Certain objects won’t support this type of rule, either for specific actions or across all actions.
Exit Region
A business object is saved when you exit a region. Hence, the business object validation rule triggers when you exit a
region 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 region.

This is the preferred type of rule for any validation. The business object validation rule type is preferred though there is
another type of validation rule (field validation). This rule type is preferred as all fields relevant to the validation rule can
be used in the sample without assuming the field in which the user has entered an incorrect value. For example, if you
have a rule - "If Assignment Category = 'Regular' then Hourly/Salaried must be 'Salaried'". In this case, though
Assignment Category comes prior in sequence to Hourly/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 in which
field the user entered an incorrect value. The question remains - should they change Assignment Category to
Temporary and leave the Hourly/Salaried as Hourly or the other way around.
A business object validation rule allows the user to enter both values, and displays an error on incompatibility. It allows
the user to decide which one to fix. It’s recommended, from a user experience standpoint, to trigger a validation rule as
soon as a user exits the field, but if it’s not feasible, you can consider the Object Validation Rule instead. Regions in
responsive pages are more compact and often the slightly delayed timing of the error message (on Continue, instead of
field tab-out) may be acceptable while allowing the user to remain within the region to fix errors.
The criteria for validation may be - any field on the current region, a field in the previous region, or a previously setup
object related to the current object. During Object Validation, even if a field in the region isn’t mapped to a column in a
table, yet all fields from the pages are transferred to the object and hence the Business Object Validation rule will be able
to use these values in the rule.
Note: This type of rule will trigger on every row that is saved. This is an important consideration when date-effective
splits occurs because of your transaction. Not only, is the new row saved but an existing row is modified or saved due to
the nature of the transaction. You will have to apply additional conditions if you want your validation only to fire on the
new row. Sometimes, these additional conditions may not be necessary as the existing rows already comply with your
validation rule.
The criteria for validation may not be a field that is part of a region not yet navigated to. You can’t warn users or show
errors in this type of rule.
If the criteria of the validation rule resides in a region prior to the current region, then it’s expected that user fixes the
value of the field in the current region to comply with the validation rule prior to going back and editing the value in the
field in the previous region.
The responsive pages won’t allow the user to go back and edit previous region if a validation error on the current region
is displayed. Once a default has occurred based on a value of a field in a previous region, if you go back and edit the
criteria field, the defaulting won’t re-occur when entering the region containing the field that was defaulted the first time
around.
You can’t default values in fields in this type of rule. While there are some exceptions to this rule, it’s important to
understand the implication of defaulting during a Business Object Validation Rule. Defaulting into another field during
object validation cycle will call the field validation cycle of that field with no provision for user interaction resulting from
errors, if any, during the field validation.

Inside Region
There are 2 potential events that can execute when the user is within a region in the responsive pages – field validation
and field modification, in sequence.
Tab-out Validate
The field validation rule is triggered first when the user tabs-out of a field. For this type of rule to trigger promptly, refer
the Auto-submit and Partial Page Refresh section.
You can base the criteria of the validation on any field that’s already accessed or entered by the user in the current or
the previous regions, or any field that has already been setup as part of Workforce Structures setup.
You can sample old and new values of the current field on which the validation rule is written. For numeric fields this can
assist with percentage change calculations. For more information on old or existing values of fields and their
comparison, refer to the Old and New State of Fields section.
What can you NOT do in this type of rule?
If the field is transient and is only on UI only but not in the model layer, then it won’t be possible to execute this type of
rule. For more information, refer to the Limitations of Autocomplete Rules section.
You can’t default values into any fields or warn users in this type of rule.
Tab-out Defaults

When the user tabs-out of a field, after the field validation type of rule triggers, the field modification rule will
trigger. For this type of rule to trigger promptly, refer the Auto Submit and Partial Page Refresh section.
This type of rule serves two primary functions -
1. Default a value in another field in the same region based on the value entered in the current field
2. Warn a user about anything after the user enters a value in the current field. The warning message can be
dismissed by clicking the OK button, and as long as the value in the current field does not change, the
warning message will not re-appear.
If the field is transient and is only on UI only but not in the model layer, then it will not be possible to execute this type of
rule. For more information, refer to the limitations.
You can’t show an error message in this type of rule.
Limitations of Autocomplete Rules

These are the limitations that you may encounter while executing your rule.
1. You want to execute a validation when the user enters a region, for example, don't allow termination if
employee is on leave of absence, you may have to rewrite this rule because it isn’t feasible to execute with the
available rule types. You will have to rewrite the rule as a Field Validation rule on the first mandatory field in the
region, which is the 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 region.
2. 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 will have to re-write your rule as an Object Validation rule that allows you to
check for values in all fields.
3. You want to warn users when they leave a region. There is no rule that supports display of warning messages
just when exiting a region. The earliest opportunity will be the last mandatory field on a given region 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 may vary between actions. For
example, during termination, the 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. The high-level compatibility of the objects for each of the four types of

Autocomplete rules is shown in the matrix below. For more information on the compatibility details for every business
object, see the section Exceptions and Recipes for each object in Autocomplete Documentation part 2 of 2. This is
available on the private portal for approved Controlled availability customers/partners only.
Author Rule Logic
For field level rules, after finalizing the object and the rule type, you also have to specify the field name on which you
want this rule to trigger.
Anatomy of a Rule

The Rule Logic is literally writing down the steps for execution of the rule starting with the very first line and stopping at
the very first error that’s shown or at the very last line.
The basic anatomy of a rule is - first declare any variables you want to use with or without any transformations, using
built-in functions (these are equivalent to some parameters of TDS). Next, use the "IF" condition block, which allows you
to achieve one of the possible outcomes - Default, Show Error, Show Warning.
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 object, you have access to all fields on the assignment, all attributes of various lookup fields such as job,
grade, business unit, legal employer, etc. and the ability to see other related parent objects like work relationship, or
child objects like work measure, etc. While the field you are defaulting or validating has to reside on the current object,
the criteria may be on the current, lookup or related objects. If the field is on the current object, you don’t have to do
anything to the sample values, but you need variables for these reasons.
1. 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 may give you further access to other
related objects.
2. Transformations: If however, you want to apply some transformation such as substring, begins with, Day of,
Year Of, etc., on the value in a field, on the current object or on a related object, you will 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.
3. UI State or System Variables: Other reasons to define variables are - to get access to special UI context (what
flow am I in, what is legislation code, and so on) or to get access to system 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.
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 keep the following data model navigation diagram in mind. There are many
combinations and number of fields from other objects that you can use. For more information, refer to the Book of
Business Objects.

You can start with any object and follow the directions of arrows (of any style) to understand what you have access to.
You can also determine the multiple-hops you may have to take in order to reach a given related object. For example, if
you want to default salary basis based on the job FLSA status using the Salary object, you need a variable to get access
to Assignment from Salary. Then you need access to job (a workforce structure setup object), from which you can then
get access to the predefined job EFF that contains the FLSA status. In some cases, stopping at the object is optional,
which means you can bypass the object. For example, Assignment to Position and then Position to Job vs. directly from
Assignment to Job.
WORKING WITH THE EDITOR
Enable a Sandbox
You need to enable a sandbox to access the HCM Experience Design Studio and Autocomplete Rules:
1. Click Navigator > Configuration > Sandboxes.

2. Click Create Sandbox.
3. Enter the Name.
4. Select the Active box for HCM Experience Design Studio.
5. Click Create and Enter.
Use these steps to access the HCM Experience Design Studio.
1. On your home page, navigate to the My Client Groups tab.

2. Click Show More to open the quick actions.
3. Select HCM Experience Design Studio in the Employment group.
Navigation Elements
In this section, let’s explore the Rule Logic section of the Autocomplete Rules editor. After selecting the business object
and the rule type, you need to give the rule a name, description, if field level, select the field on which the rule applies.
You build a rule in the Rule Logic. By default, a variable definition is displayed and you can’t delete this until you add at
least one more rule line. The rule logic editor doesn’t allow any free-form typing of logic statements. It also doesn’t allow

you to copy-paste rule lines. This is to ensure certain logical ordering of rule lines which is built into the logic editor. For
example, you can’t reference a variable or a field of a related object before first declaring it within the current scope of
rule logic.
Use these 3 key navigational elements in the Rule Logic editor to build your rule.
Down Arrow
This is the main element to add (or delete) rule lines. You can add a rule line before or after the current rule line (or
block). At the left most position of a rule line, the down arrow allows you to operate on the main body of the rule logic.
The down arrow is at the start of every rule line whether leftmost indented or indented further within a rule instruction.
The down arrows that are further right indented allow you to operate on specific sections or blocks of the rule line. Let’s
look at the additional functions along with the context in which they occur as we cover all types of rule lines.
When you click the left most indented down arrow, you can see these menu options.
1. Add Before (except for the first line of the rule logic)
2. Add Next (if there is a possible path for rule logic to proceed; may not add next after a guaranteed execution of
a Show Error statement, for example)
3. Delete (except for the only line remaining in the rule logic)
4. Delete Else Block (only for down arrows next to the If clause; more on that in the section below covering If
condition)
5. Add Else Block (only for down arrows next to the If clause for the entire If block when the Else portion is already
removed)
Within each of the above primary drop downs, you have the following options -
1. Add variable
2. Assign value to existing variable
3. Assign value to business object attribute
4. Add a condition block
5. Show error (for business object validation, field validation rule type only)
6. Show warning (for field modification rule type only)
7. Call a function
8. Add row collection looping block

xyz
The second navigational element of the Autocomplete Rules editor is the xyz icon. You can see this icon immediately to
the left of any single operand, which is part of either an expression, an equation or a function. All variable definitions are
essentially an equation and you can see the xyz icon immediately to the left of any operand (and on the right (RHS) of
the equation).
In an expression, the xyz icon is next to each operand of an expression while in a function, it’s immediately to the left of
any argument or parameter passed to the function.
You can change the type of operand or argument using the xyz element. Autocomplete Rules supports 5 operand types.
By default, one of the operand types is already picked for you by the editor and you can pick up to 4 additional operand
types. These operand types are -
1. Literal: This is the default operand type for the RHS operand for any variable type definition equation, RHS of
most expressions and most arguments of functions. In most cases, a literal operand type shows up as an empty
text box that requires input in the expected data type for that field. One exception to this is RHS operand of an
expression in which the LHS is a business attribute of type LOV. In this case, the literal automatically shows you
a list of valid values for such an LOV field.
2. Business Attribute: This is a field on any object, current or related. After changing to this type of operand, you
need to use the hyperlink to pick the attribute from the current object or a list of objects you have given
yourself access to.
3. Function: If the LHS operand data type supports a function that returns a value of the same data type,
changing to this type of operand then allows you to select the functions by clicking on the first default available
function.
4. Arithmetic Expression: If the LHS operand data type supports an arithmetic operation on a combination of
operands in RHS, you may change to this type of operand. This operand type is used in these cases.
 When you want to concatenate strings to show as part of an error message.

 When you want show arithmetic operations - add, subtract, multiply and divide operands of a like data
numeric data type.
 When you want to use it in date calculations that allow you to add or subtract a given number of days
from a date to determine the desired date prior or in future.
5. Existing Variable: When you have already defined a variable of a given data type, changing an operand to this
type enables you to substitute the RHS operand to an existing variable of the same data type as that of the LHS.

Hyperlink
The final navigational element in the Autocomplete Rules editor is the hyperlink. You can click any hyperlink to see a list
of available options. In cases where a hyperlink is available, the component shows up in blue color and the cursor in
most browsers will automatically detect it as such. The hyperlinks can show up in many contexts. Most common are -
1. Business Object Attribute: Click hyperlink to see alternative fields from current or related objects that you
have access to.
2. Operator: Click the operator hyperlink (part of an expression) to select from the alternate types of operators
available, but limited to the context of the expression.
3. Function: Click directly on the function name to select any additional available functions, again, for the context
of the equation or expression.

Variables and Functions
Common Variables
You can add these common variables using the Add new variable option. This table lists the common variables, 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, etc.
 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, etc. and subsequently
assign them to their occurrence in a transaction business object like salary, assignment,
position, etc. You may 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 (DFF) 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 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 relationships to fetch the
appropriate criteria for defaulting or validating. The special variables allow you to navigate out of the current object to
related objects to fetch the criteria. For defaulting, the starting point for your rule is the business object that contains the
field that you want to default. For validations too, your starting point can be the business object containing the fields
you want to validate, but not always.
Similar to field values in the current object, wherein any changes made by the user are still in flight without the
transaction being submitted, any fields of related objects you fetch with these variables will also be values that are “in-
flight” and not yet submitted. For example, when you navigate from salary to assignment, you will get field values in the
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 defaulting and validation rules.
 Fetch value of fields that exist in the database, for objects that are not part of the current flow. For example, if
you navigate to Assignment from a Change Salary flow, you will get values of fields in 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
The table lists the ways in which you can use the row variable.
VARIABLE USAGE
Row – Variant 1 Use row variable without getFirstRow function when you expect a 1:1 relationship between the
object you are operating on and the related object you are fetching (like lookups). After
defining a row type variable, if you use the hyperlink on the RHS, you can see the options that
allow for 1:1 relationships of the lookup codes.
Row – Variant 2 Use row variable with the function getFirstRow when you expect a 1:1 relationship between the
object you are operating on and a different object (such as a parent or a distinctly different
functional area, or a parent object). For example, when you are going from Work Assignment to
Primary Work Relationship. Accordingly, when you define a row type variable, before clicking
on the RHS hyperlink, if you click on xyz to change to function, you can see the getFirstRow
function. Click the hyperlink to see related objects that can have a 1:many (1:M) relationship with
the current object but, of which you desire the current applicable single row.
Row – variant 1

Row – variant 2
Rowset Variable
Use rowset variable when you expect a 1:M relationship between the object you are operating on and the related object
(such as going from Person to Passport or Person to Citizenship), and you want to scan all possible rows. When you
declare a rowset variable type, no further functions are supported on such a variable (you can see this when you click on
xyz. But, when you click the hyperlink, it will again show the same related objects as in the second variant of row
variable (with a getFristRow function). The difference is that you are setting up your rule to be able to iterate over all
rows of related object as opposed to just the current one.

Person related objects are functionally compact (just email, phone number, or name), and the business object that you
start with is one of the child objects, for example Passport, while the criteria is in another child object – Citizenship. For a
“Don’t allow entry of passport prior to having a citizenship record for the same issuing country” rule, you need to first
define a row variable to traverse from the first child object (Passport) to the parent object (Person), and then define a
rowset variable to go from the parent object (Person) to the other child object (Citizenship). Another example in the
same pattern of rule construction is “Ensure email address must begin with person last name”. In this rule, you need to
define row variable with getFristRow to traverse from Person Email Address to Person and then define another row
variable with getFirstRow to traverse from Person to Person Name.

Data Type Dependent Functions
You can define one variable each using the primary 6 data types as a first step in rule building. Then on the RHS side of
the variable equation, change the RHS operator type to a Function. Click on the initial default name of the first function
available to see what other types of transformations are available.
Typically, there are 3 types of functions.
FUNCTION USAGE
Standard Used for technical transformations.
Global Used to provide context information that is either, difficult if not impossible to obtain. The HCM
suite of applications provides these functions.
Object Used for authoring business objects using the Business Objects Editor (separate from the
Autocomplete Rules Editor).
Variable with functions contain part of subsequent If Logic:
The significance of the data type dependent functions is that a lot of the condition logic (with the help of an If
statement) is contained in the way these functions are setup on their corresponding variables before you author the If
statement portion of the rule logic. For example, if your rule requires you to check whether a user input text begins with
"Oracle", most standard programming languages would allow you to directly apply the transformation within the If
statement as shown below.
If <user text> begins with 'Oracle' then …
But, in Autocomplete Rules, you need to first declare a Boolean variable to test the "begins with" condition and then use
the Boolean variable in your If condition as follows –
def Boolean MyVariable = beignsWith(user text, 'Oracle')

If MyVariable = True then …
This style of application logic applies to any or all data type dependent functions like "Month Of", "Day Of", etc. Several
of these functions are very intuitive but transformations involving those that return Boolean values may be counter-
intuitive from a classical programming style perspective.

Condition Block
Condition Block inserts into your rule definition an outline of a generic If …. Then …. Else …. statement. You may want
to use this to conditionally default or validate. You can also use this to conditionally proceed only if a field or an entire
object is NOT NULL. You can change and/or add to any part of this generic outline. These are some of the common
options along with additional navigational elements specific to the Condition Block.
1. Removing the Else Block. In many cases you may not want an Else as part of your condition block. If you click
on the down arrow immediately to the left of the 'If' clause you can see the option to remove the entire
Condition block or just the 'Else" segment of the condition block, in addition to the usual "Add Next" and "Add
Before".
2. Indented (to the right) down arrows. These arrows depending on where they show up allow you to do one of
the following -
1. Add Condition: This uses the same conjunction (AND/OR) as already used in the series of conditions.
2. Add Condition Group: This allows you to cluster a set of conditions with the same conjunction inside
this cluster. You may want to add a condition group first, if you are anticipating a complex
combinatorial logic and add more condition groups to control the conjunction used within each group
and between groups. As soon as the default condition block is presented, using the indented arrow,
add a condition group and then delete the default condition statement part of the original default
condition block to proceed. You may then add as many conditions to each group and/or entire
condition groups themselves.
3. Change Conjunction: Changing a conjunction changes the conjunction for all within the same group
or all conditions without any group.
3. Remove a condition: This function has an "x" at the end of the condition. You can’t delete a condition when it is
the only condition of a block.
4. Do more than one thing if the condition is met or not. This works similar to the left most indented down arrow
allowing you to build one rule line at a time.
Default Statement
You can use the “Assign Value to Business Object Attribute" statement, which is the only way to default a value in a field.
You can have more than one such statements in a rule when all the defaulted fields are part of the same current object
in context.
When assigning a value to a business object attribute, your operand type options are limited to one of 3 -
1. Business Object Attribute: This is the default and always shows the same attribute as that on the LHS. Click
the hyperlink to change to another business attribute (field) from the current or related objects. When you do
this, you can see attributes of current or related objects of the same data type as that of the LHS operand.
2. Literal: Changing to this operand type in the context of a default statement allows you to code in (hard code) a
value to be assigned to the selected attribute. The literal appears as a text box and is based on the data type of
the operand on the LHS (the attribute being defaulted into).
3. Existing Variable: When selecting this type of operand, you can see variables that have already been explicitly
defined within the scope of the current rule line that are of the same data type as that of the LHS attribute (the
field being defaulted into). If matching data type variables aren’t available, you will get a popup message
indicating so and preventing you from changing the operand type to existing variable.
A fourth option for Operand Type, the arithmetic expression, is available, but isn’t used much in most functional
situations. You must define variables of compatible numeric types and performing arithmetic operations prior to
assigning the "Existing Variable" to the field to be defaulted as opposed to attempting an arithmetic operation during
defaulting.
Show Error
The Show Error option (available in the drop down menu when you click the down arrow) allows you to insert a rule line
that shows an error message to the user. You only have the option to show an error message during Business Object
Validation Rule and Field Validation Rule. You can’t show an error during Business Object Defaulting Rule and Field
Modification Rule types. This option will mostly be inside a conditional statement. The first thing to note is that you will
not be able to add any more rule lines immediately after this inside the execution path that includes the Show Error

statement. This is because this is the end of execution of the rule. You have no option to continue rule execution after
showing an error.
The error statement by default is shown as an equation as follows -
You can change only the RHS of this equation. By default, you can see a text box in which you can type your error
message in the language that follows your language preference of HCM Cloud login.
Click the xyz icon next to the text box to change it to either an existing variable or an arithmetic expression. The
arithmetic expression in this case is simply a concatenation of string values that’s shown to the end user. This is useful
to mix and match literal expressions with values of fields in order for the message to be more useful and specific. After
changing to arithmetic expression, each component of the concatenated string shows up with its own xyz icon allowing
you to change individual components to either literal text values or another arithmetic expression. You may want to first
setup as many components as needed before typing in your error text and/or changing some components to show
actual values of fields (of type string only). You can ignore the parenthesis, as this will result only in a sequential
concatenation of string values. You can’t change the only arithmetic operator in this context, the "+" operator. If you
want to show a number as part of your error message, you have to convert the number to a string using an object
function and store it in a string variable and then reference the string variable.
Oracle strongly recommends against showing numbers and IDs in error messages. If you want to show numbers in an
error message, you have to first convert the number to a string using an Object Function and then use the converted
string variable in the error message. To show dates in an error message, you can use Autocomplete Rules’ built-in
function to convert a date field to any format of your choice using the function "Get Date in Custom Format".
You can also setup various Boolean variables in the rule logic that detects the error condition separate from the
conditional statement where you actually show the error. This is useful to setup specific triggers in the code to trigger
specific error messages depending on what exactly went wrong when multiple conditions are checked for as opposed to
a general error message that simply says something went wrong. This is useful in pattern matching scenarios where you
can check for multiple patterns at the same time.
Show Warning
The Show Warning option (available in the drop down menu when you click the down arrow) allows you to insert a rule
line that shows a warning message to the user. You only have the option to show a warning message during Field
Modification Rule Type. You can’t show an error in Business Object Defaulting Rule, Business Object Validation Rule and
Field Validation Rule types. This option will mostly be inside a conditional statement. Unlike, Show Error, you can
continue to add additional rule lines to execute. This works like a typical warning where the user is shown the warning
message once and after clicking OK in the message, if the user does not modify the same field again, the message will
no longer show and user can proceed. If they do modify the field triggering the warning message again, the logic of the
Field Modification Rule will trigger again and if the condition triggers a warning again, it will show the warning again,
else it will pass.

The Warning statement by default is shown as an equation, much like that of an error statement as below -
You can change the RHS of this equation in same way as in case of Show Error option.
Row Collection Looping Block
The Row Collection Looping Block goes in tandem with the Rowset variable type. When you need to iterate over all
related records of a related object that has a 1:M relationship with either the current business object or another related
object, you will use a row collection looping block. The entire structure of the block is shown to allow you to only modify
the name of instance of each row of the related rowset as well as the name of rowset itself if you have more than one
rowset defined.
Execution inside the row collection will go on until the last record of the row collection. There is no way to stop execution
prior to that. You can use a Boolean variable to control the matching condition inside the loop and sample the variable
state after exit of the loop to proceed with your logic.

TROUBLESHOOTING ISSUES
Before troubleshooting issues in Autocomplete Rules, you need to consider the following aspects covered earlier in this
document.
Object-based Rule
☐ Have you identified the entry region or the exit region where you would like the rule to trigger?
☐ Have you checked region to object mapping and determined the business object to use?
☐ Does the object support the type of object rule you want, especially, default? If not, consider changing the use case
to a validation.
Validation Rule
☐ Have you identified the right object to use as a starting point when there are multiple objects being saved on exit of
a region?
☐ Have you specified the necessary condition to ensure triggering the rule only after a given region is crossed when
same object spans across multiple regions on exit of region?
Field-level Rule

Copyright © 2020, Oracle and/or its affiliates | Confidential – Oracle Highly Restricted
☐ Do you see this field in the UI? If not, confirm the region containing the field that drives the action. For example,
Action Date instead of Assignment Effective Date or Salary Start Date.
☐ Have you checked region to object mapping and determined the business object to use?
☐ Does the object support the type of field level rule you want? If not, and if, a field validation rule, consider changing
the use case to Object Validation.
☐ Does the field to be validated (or the triggering field, if field modification) have "Auto-submit" property selected in
Page Composer?
☐ Does the field to be defaulted (if field modification rule) have a PPR trigger with the Component ID of the triggering
field.
Criteria
☐ Have you identified the criteria for defaulting?
☐ Are the criteria fields visible and primary determinants of the desired user input? Forexample, Assignment Effective
Date on Worker Assignment is not editable and derives its value from the Action Date in the When and Why region.
☐ Are the criteria fields on the same object as identified earlier? If not, do you have access to these criteria fields. The
criteria will have to be on an object that has already been initiated in the flow sequence.
☐ Are you using Assignment as criteria on another object? If so, do you have IF WorkTermsAssignmentId NOT NULL
even before declaring any other row variables from Assignment or using a field on Assignment as criteria?
hcmParams
☐ Are you using the right name for the hcmParams you want.
☐ If using hcmParams, is the error displayed during HCM Data Loader (HDL) loads? Only isHDLworker is the supported
hcmParams for HDL. Other params such as Action, Action Type, and so on can’t be fetched during HDL. You will have to
sample values in fields of Objects only.
Page Properties
☐ Is the region hidden and default doesn’t work? You must not hide a region completely.
☐ Is the field in which you want to default a value hidden using TDS? TDS sets both rendered and visible property of a
field to true when done so inside TDS. Optionally, you can hide a field in the UI but you can use it while building a rule.
After going through the above checklist, identify the type of error you’re getting and follow the appropriate
troubleshooting techniques.
Type of Errors
This table lists the common errors that you may encounter while implementing Autocomplete rules.
ISSUE RESOLUTION
Rule doesn’t trigger First, test the event with a simple rule to confirm whether the issue is with the triggering
event or with the logic contained therein. This will help you in identifying the invalid
starting point - the business object or the rule type before getting into the actual rule logic.
Refer to the Test for Event section to determine if the triggering event is triggering.
Rule triggers multiple If the same error message is shown multiple times, you’re either working with the
times Assignment object where you haven’t added the IF WorkTermsAssignmentId NOT NULL
condition. Or you’re working on an Action where multiple records of the same object are
saved, like Convert Pending Worker or Change Salary. In this case, you have to add the

necessary additional condition for your rule to apply to only the record you are interested
in.
Rule triggers too early If the rule triggers too early, you’re using an object that is shared across multiple regions
and hence gets saved (and validated) at the end of each region. For example, Person
Legislative Info or Termination Info regions of respective flows. You need to either sample
values of fields in the region that hasn’t yet been encountered to condition your rule. Or,
you must use hcmParams to determine when to trigger the rule. Else, the nature of the
given object is such that it doesn’t support validation rule as it is expected to be validated
even before a region is accessed (for example, Payroll Assignment or Payroll Terms).
Rule triggers too late The nature of the given object is such that it simply doesn’t support validation rule
immediately on exit of a region, as it is expected to be validated only during Submit. Work
Measure and Salary are examples of such objects. Most objects are validated on Submit.
Works for some There are a number of exceptions where a rule only supports a given type of Action or
Actions but not others Actions or Field. If the rule falls into a known category of exceptions, log an idea in Idea Lab
to seek support for the same, In most cases, this requires significant changes in the
application.
Error in Expression ... For such errors, it’s possible that there is a bug in the tool or your specified expression in
Line# Autocomplete Ruels (like using an invalid argument for pattern matching) or you’re
fetching a value from a related object where the object itself is initialized as Null. The line
number cited in the error message has to do with the actual line number of the Groovy
code that is generated by Autocomplete Rules and NOT with the rule line in Autocomplete.
 Java Null Pointer
Check for NOT NULL after initiating a related object row definition (of Variant 1 or 2) helps
in removing this error but may not necessarily provide you with the solution. You have to
go to the Configure Business Objects task and edit your code to determine the reference to
the line number where the error is in order to fix.
 Tool bug
In some cases, given the restricted availability nature of the tool, it’s not entirely impossible
that it’s a tool bug. In some cases, you can manually fix this code in Groovy and test. But, if
you edit the rule in Autocomplete Rules that has generated this code, it will remove any
manual changes.
Error in Logic There can also be an issue with the logic. You need to know the functional relationship
between major objects and key attributes. You can build the rule incrementally, code
elements, and gradually increase complexity by introducing variables to understand where
you’re going wrong.
Test Event
1. Object Default
Use the Advanced Debugger tool, which is the only way to test Object Default event. You can use
this tool for any type of rule.
2. Object Validation
Use a simple rule that unconditionally shows an error message to test whether an object
validation rule triggers. You can run the application in the sandbox to test if this works.
3. Field Modification
Use a simple rule that unconditionally shows a warning message to test whether a field
modification rule triggers. You can run the application in the sandbox to test if this works. You
need to also check if the Auto-Submit property is enabled for the given field.
4. Field Validation
Use a simple rule that unconditionally shows an error message to test whether a field validation
rule triggers. You can run the application in the sandbox to test if this works. You need to also
check if the Auto-Submit property is enabled for the given field.

Test Using Display Variables
After testing the event, you can add an error message that shows the values of various variables in an error
unconditionally. This allows you to test if Autocomplete Rules fetches the correct values of all variables required as
criteria for default or validation rule. You must do this before writing complex IF logic to use variables to determine
precisely when you want the rule to trigger. It’s a good practice to always build your rule incrementally.
Assignment as Criteria
You need to check for IF WorkTermsAssignmentId NOT NULL condition when you’re using the Assignment business
object as criteria within another object such as Salary or Payroll. You must do this before declaring another subsequent
row variable to fetch related attributes of Assignment such as Job Level.
Advanced Debugger
1. Enable a sandbox to access the Configure Business Objects task:
a. Click Navigator > Configuration > Sandboxes.
b. Click Create Sandbox.
c. Enter the Name.
d. Select the Active box for Configure Business Objects.
e. Click Create and Enter.
f. Click Navigator > Tools > Configure Business Objects to configure business objects.
2. Scroll down to your business object and go to the right.

3. Click the gear icon and select Edit Business Logic.

4. Select your rule and edit it. Type println("add anything about the rule"); at the appropriate line.
Enter this as the very first line in case of Business Object Defaulting.
5. Validate script.
6. Click Save and Close.
7. Click Tools > Configure Business Objects from the sandbox menu.
8. Click the Display Debug User Interface icon in the menu bar under Objects.
9. Select the object, which you want to debug from the debug console.
10. Navigate to the Log window.

11. Click Clear to remove previous logs.
12. Click Start Debugging (play icon).

13. Open your application and enter sandbox with your rule against the object desired activated and ready to
run in another window. Run your application flow. When the rule is executed, change back to the debugger
tab of your browser to view the results.

OBJECT FUNCTIONS
Need for Object Functions
Object Functions supplement the Autocomplete Rules logic where it’s unable to reach the specified outcome. Object
functions are supported only in cases where capabilities of Autocomplete Rules fall short of desired solution. While
object functions provide many of the same capabilities that the tool natively provides, there are also some capabilities
that the tool doesn’t provide.
Here’s a comprehensive list of supplemental uses of object functions.
USE DESCRIPTION
Defaulting Rules Use an object function to convert the data type of the flexfield segment to the data type
expected in the transaction business object. For example, when you can't select a value to be
defaulted using the list of values (LOV) of a field in the business object, and want to select the
value from a predetermined flexfield segment of a setup entity (can be job, business unit,
organization, and so on). Depending on the return type definition on the flexfield segment -
number vs. code or name, the conversion logic inside the object function differs. The ability to
convert Big Decimal (data type of MVS flex segment) to Long Integer (data type of the
corresponding ID field on the transaction table) in Autocomplete itself is slated for a future
release. However, you can use this type of function to show a number as part of an error
message, primarily for troubleshooting, since error messages only support variables of type
string.

Defaulting or Use an object function when you have a long list of "If … then ...", where you want to reuse the
Validation Rules mapping logic amongst different rules for the same business object. Since Autocomplete
Rules doesn't have Case or Switch statements, performing this inside an object function and
returning a Boolean to indicate whether there is a match or returning the actual value of the
matching combination, may be more efficient.
Validation Rule Use an object function to validate the value received in an ID field for which there is no LOV
(for example, PeopleGroup on Work Assignment. You can create an Autocomplete rule that
does this and review the code generated as an example of how to sample the ID value inside
an object function. However, you need to write this function as sampling ID values is NOT
allowed inside Autocomplete Rules. Most IDs will have a LOV allowing you to select a specific
one.
Any rule Any calculation that isn’t provided in Autocomplete Rules. For example, date difference in
days. Refer to the Book of Business Objects and Functions white paper for a complete listing of
all transformation functions available in Autocomplete Rules, not requiring any object function.
Important:
1. Don’t use object functions for fetching related objects.

2. Don’t use object functions for assigning value to business attributes. You must return the necessary
transformed value to assign back to Autocomplete Rules and execute the Assignment inside Autocomplete
only.
How You Create and Initiate Object Functions

Use these steps to create an object function and use it Autocomplete Rules.
Create Object Function
1. Enable a sandbox to access the Configure Business Objects task:

a. Click Navigator > Configuration > Sandboxes.
b. Click Create Sandbox.
c. Enter the Name.
d. Select the Active box for Configure Business Objects.
e. Click Create and Enter.
f. Click Navigator > Tools > Configure Business Objects to configure business objects.
2. Scroll down to business object you want to work with (Salary BOVO in this example), click the Actions icon
and select Edit Business Logic.

3. Click the down arrow on the top right and select Object Functions
4. Click Add in the main editor.

5. Enter a Name, and select the return type of the function. The return type determines when the object
function is displayed in Autocomplete Rules. When you define a variable of a certain type, only object
functions returning the same data type value will be shown.
6. Expand the parameters section and click Add from the Actions menu, enter a name and select the
parameter type. The parameter type determines the type and number of variables you can pass from
Autocomplete to the object function as an input.

7. Enter the code in the main script editor section, and click Validate. You can view any code generated by
Autocomplete Rules with similar logic as a reference for how the script will be built.
8. Click Save and Close.
Initiate the Object Function in Autocomplete Rules

9. Navigate to Autocomplete Rules.
10. Select the same business object, in this case SalaryBOVO.
11. Select Business Object Defaulting (in this case) as the Rule Type.

12. Capture the Salary Basis ID from the DFF segment into a bigDecimal variable after declaring access to
related objects.
13. Convert the bigDecimal to string using your object function. Note that the object function is displayed only if
you declare a string type variable.
14. Convert the string to a number using a built-in standard function. You need to declare a variable of type
Integer for this step.
15. Assign Value to a Business Object Attribute, and select Salary Basis, in this case.
16. On the RHS, change to use Existing Variable.

Example of Groovy Code
Case/Switch
switch (vWorkSchedule) {
case 'MY_SEA_PT_OPT_0_20_ALL':
return 'Option 1 selected'
break;
case 'MY_FT_OPT_28_40_ALL':
return 'Option 2 selected'
break;
default:
return 'Cannot Identify Input'
break;
}
return true;

AUTO SUBMIT AND PARTIAL PAGE REFRESH
In responsive pages, several fields aren’t instantly updated on the underlying business object for performance reasons.
But, when you want an Autocomplete rule to be triggered specifically for certain fields, the value of the field entered by
the user needs to be instantly updated on the underlying business object. Since Autocomplete works on the model layer
operating on values of fields on the business object, until the business object receives the value from the UI,
Autocomplete will not detect a change of value in the field. Hence, you need to configure properties using Page
Composer for efficient functioning of these field-level rule types – Field Modification and Field Validation.
Auto Submit
Auto submit is a UI property that drives the business object update based on a change of value in individual field.
 For required fields and some others that drive critical business logic in the application (even without
Autocomplete), the Auto Submit property is already set to "True" (check box is selected).
 For optional and other fields, this is set to "False" (check box isn’t selected).
You can check the Auto Submit property in the UI using Page Composer using these steps.
1. Enable a sandbox and add the Page Composer tool.

2. Enter values in mandatory fields in a flow and initiate the Page Composer tool.

3. Navigate to the Structure menu of the Page Composer. You need to enter values in mandatory fields at this
stage.
4. You need to display the source code window. To do this, you need to hover your cursor towards the bottom
of the window until you see it change its shape allowing you to alter size of a sub-window. You can click or
drag-up and release to expand the source window. You may also chose to show this window on the side
using the icon at the top right of this source window.

5. Hover over the field that is the trigger for the field level Autocomplete rule.

6. Click in the field when the label and the field (text or LOV) is highlighted with a color box (both the label and
the field must be highlighted). The above screenshot shows you the correct selection. The screenshot below
shows an incorrect field component selection.
7. Select Yes when you’re prompted to edit the task flow component.

8. The source code corresponding to the field component you selected should already be highlighted.
9. At this point, you have two options.
 Option 1:
 If the field component is a predefined application field then click on the Settings icon on the
top left (second from left) to display the component editor.
 Select the Auto Submit property.
 Click Apply and Save.

 Option 2:
 If the field component is a deployed flexfield specifically for this object, scroll up the source
window slowly to find the nearest higher-level component that allows you to manage UI
properties for the entire flex segment. Click the Settings icon, to show the component editor
for the entire flex segment. Note that you won’t be able to edit the UI component properties
for individual flexfields.
 Ensure that the Auto Submit value is set to True when you’re in the component property
editor.
 Click Apply and Save.
The Autocomplete Field Validation rule is set to trigger when the triggering event (value entered in a field) is in focus
and the business object recognizes a value change in the UI corresponding to the field,.
Partial Page Refresh (PPR)

You need to configure the Partial Page Refresh property to refresh the data model. This property is used for defaulting a
value into a field (target field) on a page (not when Field Modification rule type is used for displaying warnings). If the

target field doesn’t show the value that you have set in the Field Modification rule, then this property needs to be set.
For some fields this property is already configured out-of-the-box while in others, it is not. If it isn’t set, here’s how you
set this property.
1. You need to find the component ID for the triggering field.

1. Using your browser, select Developer Tools and the web inspector. This step varies depending on your
browser.
2. Once you are in the mode of inspecting web elements, a source window that changes its value as you
hover over various fields in the UI displays.
3. If the triggering field is an application defined field, hover over (don't click), the triggering field of your
Autocomplete rule and from the source window, note down the component ID for the triggering field.
This will be all values immediately following a double colon, past the first colon (if applicable) all way
until you find a semicolon.
2. Complete steps 1 - 9 from the Auto Submit property configuration, except this time, in step 5, hover over the
target field instead of the triggering field.
3. If the target field component is an application defined field, then click the Settings icon on the top left (second
from left) to bring up the component editor.
1. Enter the component ID of the triggering field in the Partial Page Refresh field. If there is already a
value, enter it after a space following the previously entered value.
2. Click Apply and Save.
4. If the target field is a deployed flexfield, when still in the Structure menu of the Page Composer, first click on
the target field and then slowly scroll above to find the nearest higher level component - panelFormLayout
and then click on it in the source window. You can now click the Settings icon on the top left (second from left)
to show the component editor.
1. Enter the component ID of the triggering field In the Partial Page Refresh field. If there is already a
value, enter it after a space following the previously entered value.
2. Click Apply and Save. The entire UI panel will be refreshed when a value in the triggering field
changes. You don’t have the ability to change the Partial Page Refresh property on individual flexfields
like you do with predefined application fields.
OLD AND NEW STATE OF FIELDS
There are essentially 3 ways to compare and contrast old or existing values in the database with new values (changes
just entered by the user, which are still in transaction and haven’t been submitted yet). You can use this comparison to
specify conditions on validation and defaulting rules. For example, a rule that has a condition - don't allow salary
change over 50%, if a job changes from exempt to non-exempt, mark a descriptive flexfield. These are the 3 methods to
compare and contrast.
METHOD DESCRIPTION
Field Level Validation This is a quick way to compare old and new values in a single field. You can only compare
Rule old and new values, not any related attribution about the old values in the field. You can
fetch related attributes of new values, if applicable. For example, If job field changes from
101-Contractor to 102-Clerk, you can fetch the “old job ID” but, not the name or any other
attributes. You can also fetch the new job ID along with its attributes. This can only be
helpful for numeric fields to allow percent change type calculations.
Field or Object Level You can use a Boolean variable "isFieldModified" and provide the name of any field on the
Validation Rule current object to check if it has changed. The variable will only confirm if something has
changed, but can’t list the exact changes. Also, depending on the type of action (new vs
change), this may or may not be useful. For Change Salary, you can use this field to
determine if the start and end date of the inserted record has changed. This will ensure
your rule only triggers on the newly inserted record and not on the already existing rows,
which will also be updated as they may be either end aged or get a new start date based on
the period for which you are changing salary.

For example, for a new hire, you can check if the user has changed the application default
(not autocomplete default) values or entered something in an empty but optional field.
However, in most date-effective changes such as Promotion or Transfer, since a new date
effective record of the assignment is created the earlier existing values of various fields are
copied to the new record, "technically" every field is modified. The Boolean variable will
return true and can’t determine if a genuine user initiated change has been made to the
field or not.
Special access to In the Work Assignment object, a special related object, row variable of variant 2 exists to
existing Employment fetch the existing state of assignment prior to the current action in progress. This is the
related objects most effective way to confirm changes, if any, and the exact values along with the
necessary lookup information from the existing state. Similar access will be extended for
other objects related to Employment from the Work Assignment object and Action
Occurrences object for you to be able to sample your necessary criteria for a default or
validation rule.

CONNECT WITH US
Call +1.800.ORACLE1 or visit oracle.com.
Outside North America, find your local office at oracle.com/contact.
blogs.oracle.com facebook.com/oracle twitter.com/oracle
Copyright © 2020, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without
notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties
and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed
either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of
SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered
trademark of The Open Group. 0120
Autocomplete Rules
December 2020
Author: [OPTIONAL]
Contributing Authors: [OPTIONAL]


Autocomplete Rules 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Autocomplete Rules 1

Uploaded by

Copyright:

Available Formats

Autocomplete Rules

Oracle Human Capital Management

November, 2020 | Version [1.01]

2 Autocomplete Rules | Version [1.01]

3 Steps in Designing a Rule 11

Working with the Editor 19

Auto submit and Partial Page Refresh 45

Old and New State of Fields 51

3 Autocomplete Rules | Version [1.01]

WHAT’S THE AUTOCOMPLETE RULES TOOL?

Autocomplete = Autopopulate (Default) + Autocorrect (Validate)

5 Autocomplete Rules | Version [1.01]

6 Autocomplete Rules | Version [1.01]

APPLICATION VS. AUTOCOMPLETE DEFAULTING AND VALIDATION

Example of Error Message from Autocomplete Rules

7 Autocomplete Rules | Version [1.01]

8 Autocomplete Rules | Version [1.01]

WHERE DO I START IN AUTOCOMPLETE ?

Analyze the Requirement

Parse the Requirement

Employees on leave of absence can’t be terminated

Understand the Elements of a Requirement

9 Autocomplete Rules | Version [1.01]

RULE WHAT WHERE WHEN CRITERIA

10 Autocomplete Rules | Version [1.01]

3 STEPS IN DESIGNING A RULE

11 Autocomplete Rules | Version [1.01]

Region where the fields are located

Action to which the rule applies

Identify Rule Type

12 Autocomplete Rules | Version [1.01]

What can you do in the type of rule?

What can you NOT do in the type of rule?

What can you do in the type of rule?

13 Autocomplete Rules | Version [1.01]

What can you NOT do in the type of rule?

14 Autocomplete Rules | Version [1.01]

What can you do in the type of rule?

What can you NOT do in this type of rule?

15 Autocomplete Rules | Version [1.01]

What can you do in the type of rule?

This type of rule serves two primary functions -

What can you NOT do in the type of rule?

You can’t show an error message in this type of rule.

Limitations of Autocomplete Rules

16 Autocomplete Rules | Version [1.01]

Author Rule Logic

17 Autocomplete Rules | Version [1.01]

18 Autocomplete Rules | Version [1.01]

WORKING WITH THE EDITOR

1. Click Navigator > Configuration > Sandboxes.

Use these steps to access the HCM Experience Design Studio.

1. On your home page, navigate to the My Client Groups tab.

19 Autocomplete Rules | Version [1.01]

20 Autocomplete Rules | Version [1.01]

 When you want to concatenate strings to show as part of an error message.

21 Autocomplete Rules | Version [1.01]

22 Autocomplete Rules | Version [1.01]

Integer  Define a counter to add to when controlling a looping logic.

Boolean  Set up a variable to control looping structures

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

 Fetch values in the fields prior to the current flow.

23 Autocomplete Rules | Version [1.01]

24 Autocomplete Rules | Version [1.01]