What's the difference between autocomplete rules and transaction design studio?

Title and music.

Hello, in this video, I'll explain the differences between autocomplete rules and transaction design studio.

Both Transaction Design Studio (TDS) and autocomplete rules are available within the HCM Experience Design Studio. Transaction Design Studio enables you to tailor the user experience in terms of fields and sections to show, hide, or mandate based on the action criteria. Autocomplete rules takes the user experience to the next level by allowing you to define very specific criteria for defaulting and validation across the Human Capital Management (HCM) suite of products.

You may have wondered when to use one or the other. Well, you're not alone. Let’s take a look at the differences so that you can configure these components as per your business needs.

Transaction design studio is user interface (UI) driven. It allows for custom display of fields or entire regions in the user interface in the context of any given action based on a fixed set of parameters, such as the user’s business unit or country.

Autocomplete rules is a data model layer extensibility framework. It has no direct knowledge of the UI and is purely driven by the state of values in various fields of different objects. Autocomplete rules, working on the data model layer of the application, allows for custom defaulting or validation of fields regardless of whether the fields actually appear in the user interface or not.

Autocomplete rules, starts with a business object, such as the When and Why or Salary business objects.

Transaction design studio, on the other hand, is purely UI driven and starts with an action (or flow), such as the Add Assignment or Change Assignment flows.

Autocomplete Rules starts with a business object. A business object can be initiated at different places in the responsive UI and has a strong correlation to a specific section in an action. The section in any responsive UI typically operates one object at a time, although there are exceptions. Sections can be named differently according to the action, but they call the same business object. For example, Assignment Details, Employment Details, Promote, Transfer, Working Hours, all call the same business object. Therefore, if a rule is written on an object supporting these sections, the rule will trigger in all the actions it is a part of.

To configure rules in the Transaction Design Studio, you have to select an action first, for example, Add Assignment or Hire an Employee. If you want to show or hide certain fields and sections, you have to go to every action and create a rule for every action. This is because it is a purely UI driven framework.

Autocomplete rules enables you to use hundreds of criteria to default or validate, anywhere in a guided flow or static setup data. In Transaction design studio, you have just a handful of criteria to control when you want to show or hide certain fields or sections. Since Autocomplete Rules are a data model layer extensibility framework, it is applicable everywhere by default – UI, HDL, REST, and SOAP but transaction design studio is not. As you can see, both these components in the HCM design studio have quite a few differences.

This concludes the explanation of the differences between autocomplete rules and transaction design studio. Thanks for watching.