What can I do with autocomplete rules?

Hello, my name is Ken. In this video, I’ll describe what you can and can’t do with autocomplete rules.

Some examples of defaulting include:

  • Defaulting full-time or part-time statuses based on work hours.

  • Defaulting probation period based on if you are a regular or temporary employee.

  • Using defaulting for collective agreement based on custom job attributes.

  • Defaulting union and bargaining unit based on a collective agreement.

  • Using defaulting for salary basis based upon the job exemption status.

  • Defaulting the salary amount based on customer experience and custom factors.

  • Defaulting payroll based on employment details.

  • Using defaulting for time card required based on job details.

  • and much more.

Some validation examples include:

  • Using validation to prevent retroactive or future dated transactions

  • Create validation for when a field must be started on a current or future payroll cycle.

  • Use validation to prevent special characters in names and address fields.

  • To ensure phone number formats by type or country.

  • Validate If Location is x then Department must be y

  • Use validation for when you don’t want to allow terminations if employees are on leave of absence (LOA).

  • To prevent line managers from reducing salary.

  • and much more.

Autocomplete rules are not for:

  • Data synchronization, especially between HCM products

  • They are not for initiating new flows automatically (for example: automatically creating a time card entry).

  • Autocomplete rules are not for overriding application (or system) defaults, although permitted in selective cases.

  • They are not for restricting values within a list of values.

  • They are not for forcing a user to visit a region, but possible in selective cases depending on the UI.

  • Autocomplete rules are not for hiding or showing attributes on UIs.

  • They are not for validating or defaulting values on classic UIs.

  • And they are not for scanning the full data base. It’s always in the context of one person, position, job, etc.

Here are some examples of cases where you may be given a requirement and are not sure if it is compatible with autocomplete rules. As you submit your use cases we can help you make that determination (and if it is compatible with autocomplete rules, we will let you know which object and rule type should be used).

Always start with the user interface and think about if there is a field that you want to default or validate as that will give you an idea if autocomplete rules can be used.

Be sure to follow these guidelines to avoid potential conflicts between the defaulting and validation rules of the application, versus those of the Autocomplete Rules.

If data is defaulted out-of-the-box, Autocomplete Rules may not be able to override it with a custom-specific rule-based value. For example, During a promotion, the application defaults the values from the old assignment to the new assignment to use as a baseline; however, these values can be overwritten via autocomplete rules. Whereas, the filed work hours may get calculated by the application and then defaulted depending on user settings, which autocomplete rules cannot overwrite.

If all rules from both the application and Autocomplete Rules are triggered; then the resulting warning and error messages from both are displayed in the same message window.

Transactions must be validated by both the application and the Autocomplete Rules to be considered complete.

With autocomplete rules, all active rules are triggered for the same field simultaneously. Therefore, the resulting rules for warning or error messages are displayed at the same time. For example, if you define two validation rules for the department:

  • Validate department based on business unit rule, and

  • Validate there's no change in location on promotion

For a Promote flow, when you change the department, both error messages are displayed (because the location may be updated upon the change of a department). This is an example of the error messages window. The top message is generated from an autocomplete rule. And the bottom message is system generated.

This concludes the explanation of what you can and can’t do with autocomplete rules.

Thanks for watching.