HR Profile Options

There are a number of User Profile Options that are of specific importance to HRMS system administrator


HR Option Purpose
HR:Business Group Business Group that is linked to the security profile for a responsibility. This option is used online to control access to records that are not related to organization, position, or payroll.
This option is seeded at Site level with the start-up Business Group. It is view only. Values are derived from the HR:Security Profile user profile option.
HR:Security Profile Restricts access to the organizations, positions, and payrolls defined in the security profile. This option is seeded at Site level with the view-all security profile created for the Startup Business Group.
HR:User Type Limits field access on windows shared between Oracle Human Resources and Oracle Payroll. If you do not use Oracle Payroll, it must be set to HR User for all responsibilities.
If you do use Oracle Payroll, you can give each Responsibility one of the following user types, depending on the work role of the holders of the responsibility: HR User, HR with Payroll User, Payroll User
HR:Query Only Mode Restricts access to view-only for all HR and Payroll forms on a menu.
HR:Use Standard Attachments Disables the facility to attach short text comments to records. Enables the attachment of multiple items of various types including OLE objects, Web pages, images, and word processed documents.

HR Security profile

All Oracle Applications users access the system through a responsibility that is linked to a security group and a security profile. The security group determines which business group the user can access. The security profile determines which records (related to organizations, positions and payrolls) the user can access within the business group.

There are two types of security profile:

  • Unrestricted
  • Restricted

A responsibility with an unrestricted security profile has unrestricted access to data in Oracle HRMS tables. It connects to the APPS Oracle User. If you connect to an unrestricted security profile, the data you see when you select from a secure view is the same data you see if you select from the table on which the secure view is based.

When you connect to the APPS Oracle User with a restricted security profile you can access the secure tables directly if you want to bypass the security restrictions defined in your security profile. You might want to do this to perform uniqueness checks, or to resolve foreign keys.

Restricted security profiles can optionally make use of read-only, or reporting users. These are separate Oracle Users, one per restricted security profile, that have read-only access to Oracle tables and views. Reporting users do not have execute privilege on Oracle HRMS PL/SQL packages, and do not have direct access to the secured Oracle HRMS tables.

How Secure Views Work

The information that is visible through a secure view depends on the definition of the security profile through which the view is being accessed.

If you have connected with a restricted security profile the information you can see is derived from denormalized lists of organizations, positions, people and payrolls.

The lists are used only when required. For example, the payroll list is empty for a security profile that can see all payrolls, and in the case of a security profile that can see all applicants but a restricted set of employees, the Person list contains employees but no applicants.

If the HR:Cross Business Groups profile option is ‘N’, the secure views return data only for the current business group.

If the HR:Cross Business Groups profile option is ‘Y’, the secure views return data for all business groups, subject to any further restrictions that apply by virtue of the current security profile.

Security Processes

Three processes are used to implement Oracle HRMS security:

  • Grant Permissions to Roles (ROLEGEN)
  • Generate Secure User (SECGEN)
  • Security List Maintenance (PERSLM)

ROLEGEN runs automatically as part of an installation or upgrade. If you are not setting up reporting users, you need not run SECGEN.

Refer to the topic on Security Processes, Oracle HRMS Configuring, Reporting, and System Administration Guide for details of how to submit SECGEN and PERSLM from the Submit Requests window. This section describes how the processes work.

ROLEGEN: Grant Permissions to Roles Process

A role is a set of permissions that can be granted to Oracle users or to other roles. Roles are granted to users by the SECGEN process (see below).

The ROLEGEN process must run before you run SECGEN. ROLEGEN dynamically grants select permissions on Oracle HRMS tables and views to the HR_REPORTING_USER role. This role must exist before ROLEGEN runs.

The HR_REPORTING_USER role is created during the install of Oracle HRMS. ROLEGEN is run during the install of Oracle HRMS.

Note: As ROLEGEN runs as part of the installation and upgrade processes, you do not need to run ROLEGEN manually.

ROLEGEN performs the following actions:

  • Creates public synonyms for HRMS tables and views, excluding unsecured tables (%_ALL_%)
  • Revokes all existing permissions from HR_REPORTING_USER roles
  • Grants SELECT permissions to HR_REPORTING_USER role for HRMS tables and views

SECGEN – Generate Secure User Process

You run SECGEN for a specified security profile. It grants the HR_REPORTING_USER role to the Oracle User associated with the security profile.

SECGEN must be run after ROLEGEN. However, once SECGEN has been run for a particular security profile, you need not rerun it even if ROLEGEN is run again.

SECGEN is a PRO*C process with embedded SQL statements. You initiate it from the Submit Requests window.

PERSLM – Security List Maintenance Process

You should run PERSLM periodically (for example, nightly) to refresh the security lists upon which the secure views are built.

Important: This process has the capability to run multi-threaded, allowing it to take advantage of the capabilities of your hardware.

PERSLM is a PL/SQL procedure that you submit from the Submit Requests window. It builds the required security lists based on the restrictions defined for the security profiles being processed.

Create Grade API

/* =====================================================================

— PROGRAM TYPE : Procedure

— DESCRIPTION : This is used to craete grade
— INPUTS : None
— OUTPUTS : None
— ===================================================================*/

CURSOR cur_grade
FROM xxhr_grade_stg
WHERE process_flag IS NULL;

l_grade_id NUMBER := NULL;
l_object_version_number NUMBER := NULL;
l_grade_definition_id NUMBER := NULL;
l_name VARCHAR2 (500) := NULL;
l_err_msg VARCHAR2 (500) := NULL;

for r_grade in cur_grade

HR_GRADE_API.create_grade (
p_validate => FALSE,
p_business_group_id => fnd_profile.value(‘PER_BUSINESS_GROUP_ID’),–82, — Business Group ID
p_date_from => TO_DATE (’01-JAN-1950′, ‘DD-MON-YYYY’),
p_sequence => 22,
— p_date_to => TO_DATE (’31-DEC-4312′, ‘DD-MON-YYYY’),
p_segment1 => 22, — Segments Defined in Grade KFF
p_grade_id => l_grade_id,
p_object_version_number => l_object_version_number,
p_grade_definition_id => l_grade_definition_id,
p_name => l_name

UPDATE xxhr_grade_stg
WHERE record_no = r_grade.record_no;
l_err_msg := SQLERRM;
— DBMS_OUTPUT.put_line (‘Inner Exception: ‘ || l_err_msg);
UPDATE xxhr_grade_stg
error_msg =l_err_msg
WHERE record_no = r_grade.record_no;

end loop;

Defining Full Name format In HRMS

Global Super HRMS Manager > Other Definitions > Person Name Formats

Pre-requisites:                Set system profile HR:Local or Global Name Format

value = Local Format

Click on Create New Format

Format Type Legislation User Format Choice
Full Name Malaysia Local Format


Sequence Space Punctuation Space Component Space Punctuation Space Move Up Move Down Delete
1 Prefix
2 Last Name
3 Title
4 First Name
5 Middle Name
6 Preferred Name


Click Apply


Update Person Names – Concurrent Program

Responsibility :Global Super HRMS Manager


Create Person Name Formats

Set system profile option


Concurrent Program

Update Person Names



Format Type Legislation Disable Who Trigger
Full Name Format Malaysia Yes

Adding Values to value set in 12.2.3

For adding values to value set in 12.2.3 first grants and security needs to be set.

Setting up value security mostly consists of creating grants using the Functional Administrator responsibility.

The grant has three basic parts that we assign when we create the grant:
1. Grantee and security context (who gets privileges and the context where privileges are available)
2. Data security object “Flexfield Value Set Security Object”, object instance set, and parameter values if needed (what data is affected by the grant)
3. Permission set (what privileges are allowed on the object)

New Value Sets
No users are allowed to view, insert or update any value set values unless access is explicitly granted. You must explicitly set up access for specific users by enabling appropriate grants and roles for those users. That restriction includes values for value sets created by the same user. For example, if a user creates a new value set definition using the Value Set window and immediately goes to create values for that new value set, the user will not be able to find or enter values for that new set unless:





Creating User and adding responsibility from back end

/*****************Add User********************/
LC_USER_PASSWORD VARCHAR2(100) := ‘welcome123’;
ld_user_start_date DATE := sysdate;
ld_user_end_date VARCHAR2(100) := NULL;

( x_user_name => lc_user_name,
x_unencrypted_password => lc_user_password,
x_start_date => ld_user_start_date,
x_end_date => ld_user_end_date



/********************add responsibility*********************/

lc_user_name VARCHAR2(100) := ‘PRAY’;
lc_resp_appl_short_name VARCHAR2(100) := ‘SYSADMIN’;
lc_responsibility_key VARCHAR2(100) := ‘SYSTEM_ADMINISTRATOR’;
ld_resp_start_date DATE := sysdate;
ld_resp_end_date DATE := NULL;

( username => lc_user_name,
resp_app => lc_resp_appl_short_name,
resp_key => lc_responsibility_key,
security_group => lc_security_group_key,
description => NULL,
start_date => ld_resp_start_date,
end_date => ld_resp_end_date