Oracle HCM Cloud – Creating Dependencies between Functionalities

Oracle HCM Cloud is a tightly bound system which allows for very less customization. You can customize page to make fields mandatory, remove fields from page, hide fields etc. However, what does an implementation consultant do when faced with a situation to make a certain functionality mandatory based on another functionality. For example: A person should be able to submit expenses only if he is eligible for it and the eligibility is defined in core HR. How would one link these two modules and ensure that the expense report submission is based on the employees eligibility.

A very simple way to do this would be Oracle HCM’s delivered Descriptive Flexfield functionality. Following steps define how to achieve the scenario and create dependencies:


A DFF in core HR is defined to mark employee’s eligibility to claim expense. Let’s call this DFF as “expense eligible”. If this value is checked then the employee is eligible else employee is not eligible. Also the employee is eligible if he was hired with an action reason “expense eligible”.


Define a DFF on the expense page and mark is as mandatory. Once the DFF is defined attach a valueset to the DFF. The valueset would be based on SQL Table and in the query select ‘Yes’ if employee’s hiring action reason is “expense eligible” and the “expense eligible” DFF in core HR is checked.

So at the end of above definition, you would have a DFF in expense which would have a dropdown with value ‘Yes’ if the employee is eligible for expense and nothing in drop down if the employee is ineligible. Now since the DFF is mandatory, if the employee is in eligible he would not be able to go ahead with submission since the DFF would not have any value.

This way we can achieve the functionality to make pages dependent on each other.




Oracle HCM Cloud – Viewing Employees from UI

Data conversions is one of the most important part of any ERP implementation. In the HCM world employee data conversion is most critical aspect. All the other data entities can be converted once the employee is converted. In almost every HCM product the employees can be viewed from the UI once the base tables are updated. However, this is not true in case of Oracle HCM Cloud.

In Oracle HCM cloud the users are expected to run the Update Person Search Keyword process. This process populates a table called PER_KEYWORDS which indexes all the employees and enables them to be searched from the front end. The twist in the tale is that PER_KEYWORDS table is populated only if a person has a local name populated in the PER_PERSON_NAMES_F table. Names table has a field called NAME_TYPE. An employee should have a row in this table where NAME_TYPE is not GLOBAL.

During conversions, or inserting data via an interface, when an employee is created it should be ensured that the work relationship data contains PrimaryFlag and has a value of ‘Y’. Doing this ensures that a local name is created. If this value is not passed then primary flag is defaulted to ‘Y’ however a local name is not created. Hence PrimaryFlag should explicitly be passed as ‘Y’.

NOTE: Local Name is created only when PrimaryFlag=’Y’ is passed when an employee is newly created.



Oracle Cloud – PII Data security

This article has details around how Oracle cloud preserves data security especially around PII (Personally Identifiable Information) data. In the HR space PII data is highly sensitive as it contains employees name, date-of-birth, SSN, address, phone and email details. Hence it is important to protect these.

In order to protect this data Oracle has several roles created. The user would need these roles to see the data from the UI as well as to query them through BI Publisher. The list below provides all the table names and roles created for them: