Flex Fields

Flex Fields in HRMS

We already know about the flex fields; KFFs and DFFs, and also the related setup instructions. However let’s see the role of the flex fields in Core-HR implementation.


Let’s pick KFFs first. As we have discussed already, there are around ten KFFs in Oracle HRMS; out of which six are mandatory for a successful Core-HR implementation. The mandatory KFFs are:

  • · Job
  • · Position
  • · Grade
  • · People Group
  • · Competence
  • · Cost Allocation

Apart from the mandatory ones, there are a few optional KFFs present in the Oracle HRMS. Like: Personal Analysis, Collectively Agreed Grades Flex field, Soft Coded Key Flex field, Bank Details Key Flex Field, Training Resources and Item Contexts Key flex. Now the task is to identify and define the different KFFs that we need for the implementation.


For Even if we do not need segments of a particular KFF, it is advised that we define a dummy segment and make the display as off. Because there will be cases where presence of at least one KFF segment will be necessary; in order to make a functionality work. So better have it ready from the beginning.


Now, talking about the DFFs, The Descriptive Flex Fields are the ones that store the additional information based on any table; the information that are not being captured by the attributes supplied by Oracle.

There will be situations, where we will need a particular data to be captured somewhere and the table would not have a seeded place to store it. We will have to figure out such data fields and use that table’s DFF to store the data. We must practice caution while using contexts to relate them to appropriate segments.

Extra Information Types

The Extra Information Types or EITs are DFFs attached to six very important entities that help us capture extra information, that are not available in our tables. It is kind of a DFF. Now, the question, why something called an EIT is introduced, if there was a concept of DFF already there?

  • EITs are stored in different tables, where as DFFs are stored in the same very base table. So any changes the base table, creates extra rows for DFFs, but EITs stay intact, making it more normalized.
  • EITs do not store historical information, neither are they date tracked. So any information which is static (data that hardly changes) can be put in EITs and others in DFF.
  • EITs are enabled at the responsibility level, enhancing the data security a lot better than the way DFFs do.

EITs in HRMS are given to only six entities:

  • · People
  • · Assignments
  • · Job
  • · Position
  • · Location
  • · Organization

Let’s see how to configure one. We will first learn the EIT creation for all other EITs except the Organization one. We will discuss about the Organizations later. See Figure 2.5 – EITs.

Responsibility: Application Developer

Navigation: Flex Field -> Descriptive -> Register


  • · Put the name of the table in the Table Name Field
  • · And query the table.
  • · It should list all the DFFs based on the table. From there, pick the one with Extra Info. See Figure 2.5 – EITs.
  • · Copy the Title.

Figure 5 EITs

(Figure 2.5 – EITs)

Now, go to the Segments.

Responsibility: Application Developer

Navigation: Flex Field -> Descriptive -> Segments


  • · Query for the Title in the table
  • · Now create or update the contexts with new segments, with the same steps we created a DFF.
  • · Once done, freeze and compile the DFF.
  • · Now the EIT is created.

However the EIT must be linked to the responsibility that we are using. Only after the EIT is linked to the responsibility we will be able to use the EIT with that responsibility. This is an additional security feature. For an example, we might not want to allow our Payroll User to view /update someone’s location DFF. In that case just do not link the EIT to the payroll user Responsibility. Let’s see how to link EITs.

Responsibility: Super HRMS Manager

Navigation: Security -> Information Type Security


  • · Query for the Responsibility we want the EIT to be linked to. See Figure 2.6 – Linking DFFs to Responsibilities
  • · Add a new record with the EIT context name in the drop down.
  • · Save the record.

Now we can use our EIT.

Figure 6 Linking DFFs to Responsibilities

(Figure 2.6 – Linking DFFs to Responsibilities)

Before creating an EIT, we must make sure there are ample reasons for us to create an EIT. We must know the segments we are going to need and the respective value sets as well. Once we have all the information and we are convinced that we need an EIT to achieve what we are looking for, only then we should go for it.

While creating the EIT for organization types, we need to consider the classifications; because the EITs are actually linked to the “HR_ORGANIZATION_INFORMATION” table, not the actual organization table. Now, what are organization classifications? These are the different attributes that define an Organization better. We will discuss more about them later in this chapter. As of now, let’s consider adding up EITs on to them. The Organization classifications are present in an extensible lookup type: “ORG_CLASS”.

To create the EITs, we must go to the Register screen and look for “HR_ORGANIZATION_INFORMATION” table. Now we will find a title named: “Org Developer DF”. Now open the segments and look for the EIT we want to update. Please remember, Organization data are very sensitive for the reason that, they represent the firm with respect to reporting to Government and Legalization. Hence before creating or updating an EIT of that sort, we should always be very cautious.

Special Information Types

Special Information types or SITs are KFFs. These serve the same purpose as the EITs do, which is additional data storage. However as it is a KFF; it stores data in form of combinations unlike EITs do. We can use SITs for Job, Position and Personal analysis in Oracle Core-HR. Let’s have a look how to implement one.

  • Go to KFF Register
  • Register the new KFF, as an instance of the Personal Analysis KFF
  • Update/ add the segments that you need against the SIT
  • Enable the SIT in the business group

Please remember, SITs do not need any responsibility linking like EITs do, which makes SITs less secured than EITs. Hence it is advised to chalk out the data design that we are planning to store in SITs, consider the usage and security etc; before going ahead and creating the SIT and the segments.


As the enterprise has employees, there will be jobs to fill in; Positions to support the type of job with details, People Group to classify a set of employees for a given purpose. However all these are data fields/ columns, which are used to represent some or the other characteristic of the Employee's assignment.

Job is a generic Role within a business group that tells us more about the assignment carried out by the employee. It is independent of a Division / Department. Like, Manager, Director and Programmer are Jobs. Jobs are stored in PER_JOBS. It’s a dated table. The Job Id is the primary key here, and acts as the foreign key to the PER_ALL_ASSIGNMENTS_F, to link the job to a particular assignment. So let’s shift our focus on how to create and use a job.


This is the first step. Job KFF stores the basic information related to the jobs available in the firm; like we have job like a manager, a technical assistant etc. So this is the place where we define those jobs. The first thing that we need is the list of segments we want to use in the Flex Field. So the question we ask ourselves / the business is, what all do we want to store in a Job? Do we need the job name, the occupational function, the title s/he shares, etc? Once the segments are determined, the next step is to figure out the valid values for each and every segment; and create corresponding value sets.

For an example, if we were to create a job, and our firm wants us to store the job name, job code and a functional title, we will define the different job names, codes and titles available at my firm, and then create value sets based on that. We can go for a quick code that stores the job names and codes, and another quick code to store the titles. We will configure the value set in such a manner that, it will show me the values that are in the quick code. And will attach the value set with the segments.

Now, as the segments are decided and the value sets are defined, the next stage is to configure the KFF. See Figure 2.2 – KFF definition.

Responsibility: Application Developer

Navigation: Flex Field -> Key -> Segments


  • · Query for the FF titled: Job Flex field
  • · Create a new row with appropriate data

Figure 2 KFF definition

(Figure 2.2 – KFF definition)

We have already discussed the steps to create a KFF, so we are not going to revisit that; however we must understand the application of the segments, which will be added to the Job KFF. So let’s go to the Segments tab and start adding the segments one by one, with a sequence. The name and window prompts are self explanatory. Column is the segment with which the data will actually be stored in the table. We can choose segment 1 to 30. And value set field is the place where we attach our value set. If we wish we can save a segment without a value set that will allow the users to enter any alphanumeric value in it, up to 150 chars. However it is always advisable to create a value set even if it’s a free text.

If we continue with our example, we will create three segments, somewhat similar to the Figure 2.3 – KFF Segments.

Figure 3 KFF Segments

(Figure 2.3 – KFF Segments)

Once the Segments are defined, close the segments window and freeze the KFF Definition. And Compile it. Finally run the Run Create Key Flex field Database Items Process. Do not forget to update our lookup types used in our Value sets with available values.

Job Groups

The Job Groups are a collection of jobs. Every business group must have a default job group so that all the jobs can be grouped under the same. However in a case where there is a different line of jobs needed, we can go for a new job group altogether. See Figure 2.9 – Defining Job Groups.

Responsibility: US Super HRMS Manager

Navigation: Work Structure -> Job -> Job Group

Figure 9 Defining Job Groups

(Figure 2.9 – Defining Job Groups)

Setting up Jobs

Next task is to add jobs. See Figure 2.10 – Defining Jobs.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Job -> Description

Figure 10 Defining Jobs

(Figure 2.10 – Defining Jobs)


Position is a specific instance of Job, within an Organization. Like, Accounts Manager, Information Security Manager are Positions, where as Manager is the Job. If we excavate a little more, it’s more like a specific type of Job that an assignment is assigned to, with specifics related to Organization / Location / Departments. Job is the superset of the positions. Positions are stored in PER_POSITIONS, and like Jobs have JOB_ID, the linkage to assignments for positions is done through POSITION_ID.

Question: Is it a Role?

No. Although Role is just a concept, often used in HRMS, there is no such table that stores roles in here. We are not talking about User-Roles here. Role, as the name suggest is the type of act the concerned assignment is doing. It’s very different than a position.

One example will help us understand it better.

An accountant, who is a Finance Manager, is acting as a CFO in ABC Inc.

In the statement above, Accountant is the JOB, Finance Manager is a POSITION and CFO is the role he is acting.

Position KFF

As we had discussed earlier, Position represents a particular instance of the job. It is time to capture the positions and the underlying segments. We know the steps,

  • · Figure out the segments we will be using in a Position KFF
  • · And then create the value sets and if necessary the lookup types as well
  • · Go to KFF screen, look for Position Flex field
  • · Create a new one with the new segments
  • · Then freeze it and compile it
  • · Do not forget about the “Create Key Flex field Database Items Process”

Setting up Positions

As we have the KFF defined, let’s see how to create a new position.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Position -> Description

Position Hierarchy

The Position hierarchy is more or less similar to what we have in the Organizational hierarchy, but here, the structure is based on the Positions. Like, for an example, our firm has clerks, then Senior Clerks, Line Mangers, Managers, Senior Managers etc, and the reporting structure is in the same order, isn’t it? Now where do we store this information? This is where it is done. We define the positions and define a hierarchy.

The configuration of position hierarchy is exactly the same way we do the Organization Hierarchy, so is the Diagrammer. So we are not going to explain anything on this one, we can try it by ourselves and it should be very simple.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Position -> Hierarchy / Diagrammer


Locations are the physicals addresses / sites where we have our Firm placed. It could be our corporate office, our Manufacturing centre or Sales Office. Location is a very simple concept to understand.

There are two types of locations, Global and Local. A location with Global Scope can be seen and used in more than one business groups; however the one with Local scope can be used only with the business group it’s created. See Figure 2.8 – Defining Locations.

Figure 8 Defining Locations

(Figure 2.8 – Defining Locations)

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Location


The enterprise uses grades to compare roles within their organizational structure and relate compensation to grades to pay their employee in groups. Grades are stored in PER_GRADES. The primary key GRADE_ID acts as the foreign key in assignment table to create a relationship with in grade and assignments.

Let’s start with an example. A firm has different positions. And in one position, there are different levels. Like someone who is a Production manager, might have a level as L5, but another Production manager might have 3 years of experience in the same position and he might have a level as L6. So L6 is a higher level than L5. The levels are usually called grades.

Grade is a part of grade step progressions functionality. Although in today’s world Grade is used across firms, however grade step progression is not used a lot. So in this section we will focus only on grades and their usages. We will discuss about grade step progression though, but only after we understand Grades completely.

Grade KFF

This is the KFF that is going to hold our grade related information of our firm. For an example it might look like this: “L6.Senior.Technical”. This typically de[ends on the business reqirement. Oracle E-Biz gives us the liberty to store as much information to store as we wish to in the Grades. That’s why it’s a KFF. Now, on the setup part of the KFF, the steps are similar to the Job and Position KFFs.

  • · Figure out the segments we will be using in a Grades KFF.
  • · And then create the value sets and if necessary the lookup types as well.
  • · Go to KFF screen, look for Grades Flex field.
  • · Create a new one with the desired segments
  • · Then freeze it, compile it and run “Create Key Flex field Database Items Process”

Setting up Grades

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Grade -> Description


  • · Enter the sequence number.
  • · Enter a name of the grade. If there are more than one segment in grades KFF, fill them in.
  • · A Short name can be entered.
  • · Enter the From and To Date.
  • · Add in the details in any of the EITs if any.

That should be all. Simple, isn’t it?

There will be instances where one grade has spun across positions. Meaning, two people might be in a single grade but with two different positions; so we cannot really say, grades belong to positions; unlike the relationship between jobs and positions.

Grade Rate

Once the Grade is defined; the next task is to define the grade rates. The Grade rates define a salary range for each of the grades. An employee of that grade is liable to be within the salary limits. If the Employee crosses the salary limits, system throws a warning, not an Error.

Let’s go define it.

Responsibility: Super HRMS Manager

Navigation: Work Structure -> Grade -> Grade Rate


  • · Enter Name of a rate.
  • · Put units as Money.
  • · Select a Grade from the drop down with a currency
  • · Key in a Minimum and maximum value, and the mid value must get calculated automatically.

Grade Rates are very useful for Salary surveys, to tell the employee’s manager, where he stands in his grade scale, and how far he is from the mid value etc.

Grade step progression

Usually the Performance Management planning flow is to promote a Person from one grade to another when there is a performance review. Once the grade increases the salary is also increased. However in some firms, where the promotions are managed through the years of experience or points, the grade step progression comes handy.

How it works is, we set up rules of eligibility to get into a Grade. So if someone passes the criteria he will be moved to next grade. The eligibility can be based on Years of Service, points etc. Once the Employee gets the value, he moves to the next grade and so does his salary.

For an example, we will set it up like this: If someone is a Production Manager since one year, the grade is L4, if two years, it is L5 and likewise, so If Mr. Joe is L4 and completes his second anniversary as a Production engineer, he should get promoted to L5 automatically, and his salary should also change to the band of L5. So the promotion becomes an automated process, but now-a-days, the competition defines the promotion not the Years of Service; so Grade Step Progression is not a widely used functionality.