1. Configuring and Extending HCM Using Autocomplete Rules
  2. Considerations for Rule Designing

Considerations for Rule Designing

Look at the existing functionality and analyze your requirements before creating an autocomplete rule. Analyze whether Autocomplete Rules can help meet your requirements sub optimally or totally.

Not every requirement that reads like ensure, default, validate, prevent, don't allow, or synchronize can be met using Autocomplete Rules. These are the things to consider:

Requirement Parsing

Highlight specific words in the requirement you want coded and determine the sample values in the object field. Think about the UIs where you want to see the effect of the defaulting or validation rule. This isn't explicitly specified in the requirement. Also, consider some implicit criteria such as only for a given user role. These implicit requirements are used more in validations rather than defaults. Let's look at some examples:

  • 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 data am I validating?

  • Employees on leave of absence can't be terminated. - This answers the question: What fields am I validating?

Fields to Validate or Default

The first part of the requirement is to identify the fields you want to default or validate. It's important to identify the section containing the field. For example, if your use case is to validate Assignment Effective Date, then most likely, you want the rule to trigger in the When and Why section where the date is required.

If you can't identify the fields, identify the section where you want the rule to trigger. If you can't identify the section, then it may not be feasible to implement an autocomplete rule. For example, implementing the rule, Don't Allow Withdrawal of Termination, may not be possible because Reverse Termination is a button on a page that doesn't involve any field or section.

You also need to look at out-of-the-box delivered default values or validations. In some cases, if a field is defaulted out-of-the-box, Autocomplete Rules can't override it with a customer-specific rule-based value.

User Experience

The second part of the requirement is to focus on the user experience. This is critical for determining the feasibility. You need to focus on the guided process flow in the responsive UIs when determining the user experience. Autocomplete Rules can execute a specified validation, but the validation is triggered only when the transaction is submitted and doesn't allow the user to go back and edit. A point to note is that the validation is triggered in these scenarios.

  • When entering a section

  • When tabbing out of fields

  • When exiting a section

This helps in deciding the rule type to use and the execution of the rule. After understanding operation of the data model elements and the UI, you may have to change your requirement to something sub-optimal, yet acceptable.

Rule Criteria

A key part of the requirement analysis is to list out the criteria for defaulting or validating a field. Some criteria involve current fields while some involve sections that the user has already crossed or involve some predetermined setup data. Here, you need to focus on whether the criteria is known or is something that's 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 or fields in the sections yet to come, although with some exceptions.

When identifying fields that are to be defaulted or validated as in the first step of the requirements analysis, or fields that are to be used as criteria as in the last step of the requirement analysis, you must not use a field that's not visible or editable in the responsive pages either out-of-the- box or using the Transaction Design Studio. For example, let's say you 're working with Worker Assignment and want to check the action code, you must not use the action code in the Assignment object but use the action code in the When and Why object because this is the section where the action is both visible and editable. HCM application will synchronize values within and across sections, as you progress through the responsive pages. But the timing of availability of values in these fields can't be guaranteed unless they're visible to the user and editable in the responsive pages. In addition, several fields that are shown by the Autocomplete Rules UI are reserved for application use only.