Oracle Human Resources Management Systems Configuring, Reporting, and System Administration GuideRelease 12.1

Security Rules

Security Overview

Defining which records and information users can access is fundamental to HRMS security.

As part of your implementation plan, you identify who will use Oracle HRMS, what information they require, and how they use it. You can control a user’s access to database elements such as records, fields, forms, and functions, and you can also control a user’s access to other user records and data.

All Oracle Applications users access the system through a responsibility that is linked to a security group and a security profile. The responsibility is the primary means of defining security. 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. For example, you can restrict a manager’s security permissions so that the manager can only access the person records for those employees and workers within a supervisor hierarchy. This restriction enables secure, reliable data access and ensures that only people with the correct permissions can access personal data.

See: Responsibilities

---

Security and Business Groups

In general, a user can only view the records for one business group at a time. However, depending on the value of the HR:Cross Business Group Profile option, you can view specific information across business groups. See: User Profiles

See also: Single and Multiple Business Groups, Oracle HRMS Enterprise and Workforce Management Guide

Within a business group you can control:

• Who the user can access, using security profiles. You can restrict access by:
  
  • organization hierarchy
    
  • position hierarchy
    
  • supervisor hierarchy
    
  • payroll
    
  • supervisor assignment
  You can also restrict access to specific person types, for example, employees, applicants, contingent workers, and, if you are using iRecruitment, candidates.
  You can also create your own custom restrictions and combine them with the standard restrictions. 
  Note: You can configure the above security restrictions to be user-based. The application evaluates the security permissions dynamically for the user currently logged on to the system. User-based security profiles can be used by multiple employees which reduces set-up and administration tasks.
  
• What the user can access. You control user access to specific functions using function security. You attach functions to menus which you then attach to responsibilities. By linking the functions to responsibilities, you can restrict which users can access particular functions, and on which menus the functions appear. By modifying the function parameter information, you can define how the function operates and processes information.

See: Menus

See: Defining Menu Functions

Key Concepts

For more detailed information on security concepts, see:

• Security Models
  
• Security Profiles
  
• Responsibilities
  
• Security Processes

Security Rules

You can set up and maintain security of access for different classes of users. Once you have identified who will use Oracle HRMS, what information they require, and how they will use it, you can group together users with similar requirements and give them the same view of the system.

AuditTrail is an Oracle HRMS system administration task which enables you to track and record changes to your data.

In what ways can you use security of access for different users?

You can set up menus using structures and names that make sense to the users. You can also restrict the data users can view and edit in certain windows, so they only see what they need to see.

This provides security for your data and an efficient interface designed for your users’ needs.

How does Oracle HRMS allow data restriction for display in a window?

If you want different users to view the same window for different purposes, you can restrict their views in different ways. For example, you can:

• Limit access to list of values for faster data entry
  
• Limit access to certain types of information
  For example, you might create a configured version of the View Element Entry History for Employee form that does not display the earnings elements representing salary, bonus and commission. Most users’ menus would only give them access to this configured version of the form. Those authorized to view salary, bonus and commission figures can have a menu function defined to allow access to the standard version of the form.

How does Oracle HRMS enable users to view multiple business groups?

Oracle HRMS is installed with two security models, each enabling you to set up security for an enterprise which uses multiple business groups. Using either model you can only view records for one business group at any one time, except in cases where the HR:Cross Business Group user profile allows access to specific fields across all business groups. See: User Profiles.

The difference between the models is as follows:

• Using Standard HRMS Security you can only link one business group to one responsibility. You must set up different responsibilities for each business group.
  
• Using Security Groups Enabled Security you can set up more than one business group for a single responsibility. However, you still only view records for one business group at a time.

What does AuditTrail provide?

AuditTrail provides a flexible approach to tracking the changes to your data. It enables you to keep a history of changes to your important data: what changed, who changed it, and when. With AuditTrail, you can easily determine how any data row or element obtained its current value. You can track information on most types of fields, including character, number and date fields.

Can you link windows together?

Yes. Oracle recognizes that to complete many tasks, you need to use more than one window. You can link these windows together in a task flow so that you can choose a button to bring up each window in turn without returning to the menu.

Security in Oracle HRMS

Key Concepts

The following definitions describe the key concepts in Oracle HRMS security.

Menu Structures

Using menu structures, you can limit the functions a user can access. You can also restrict access to information types by choosing which information types a user can view.

You can also create multiple versions of the same form, each one used for just one task. This approach restricts the list of values on certain fields and therefore provides for faster data entry. It also  enables you to limit access to certain types of information.

Reporting Access

You can set up access restrictions for employees who never use the product’s windows and do not change database information, but do access the database.

Request Groups

You can specify which processes and reports a reporting user can run by setting up request groups. Within the request group, you use security profiles to restrict the records accessed by the reporting user, who may run reports against the system without having online access through the system’s forms.

Responsibility

The responsibility is your primary means of defining security. Business groups, menu structures, task flows, and information types are linked to a responsibility.

Security Groups

Security groupsare a method of partitioning data. If you are using the Security Groups Enabled security model, you can manage information for multiple business groups using one responsibility. This is particularly useful if you are a Service Center. Security Groups Enabled security is also useful for organizations using Oracle Self Service HR and organizations with employees that must access and manage records from different business groups.

Security Models

The two security models, Standard HRMS Security (Security Groups Disabled) and Security Groups Enabled security (formerly called Cross Business Group Responsibility Security), both control security by restricting who and what the user can see. What differs is how you set up security, menus and how users log in. For more detailed information about each of the security models, see Security Models.

Security Processes

System security processes enable you to:

• Grant permissions to a new reporting user.
  
• Maintain the lists of organizations, positions, payrolls, employees and applicants that security profile holders can access.
  
• Set up and update your system to use the Security Groups Enabled security model.

Security Profiles

By defining security profiles, you can control access to records of employees at or above a certainlevel in an organization. For example, you can give a department’s administrator access to all department employee records except those of the manager and assistant manager.

User Profiles

A user profile is a set of changeable options that affects the way your application runs. You can set user profile options at site level, application level, responsibility level and user level.

You can restrict access to query-only for all or a selection of your HR and Payroll forms using a user profile option and the parameter QUERY_ONLY=YES at form function level.

Security Models

Oracle HRMS provides two different security models which enable you to set up security specifically for your enterprise: Standard HRMS security and Security Groups Enabled security (formerly called Cross Business Group Responsibility Security).

Note: If you want to set up security for employees who can access the database, but do not change database information, see: Reporting Access and Setting Up Reporting Users.

A further option exists which enables users to simultaneously view selected fields from all business groups in your organization regardless of the security model. For more information see HR: Cross Business Group Profile option.

Standard Security Model

Standard HRMS security restricts access to your enterprise’s records and data. To set up Standard HRMS Security, you first create responsibilities and then define the windows, menus items, workflows, data and records the user can access. The System Administrator then assigns users to as many of these responsibilities as is required to complete their business tasks.

If you are using Standard HRMS Security, you must ensure that the Enable Multiple Security Groups profile option is set to the default value No. You must then create a security profile for each distinct security grouping of employees your enterprise requires.

You then create a responsibility for each user type you require, for example HR Manager, Branch Manager and Salesperson, and link the security profile and responsibility to a business group. These three elements create a security grouping to which you assign employees.

Assigning Users to a Responsibility, Security Profile, and Business Group

Note: Each security grouping you create restricts access to the business group to which the security profile and responsibility are assigned.

By assigning users to the security grouping, you grant them access to the records, menus and data defined in the security profile and responsibility. You can add further users to this security component, but you cannot re-use the security profile and responsibility within another business group.

Your enterprise can also set up request groups to restrict user access to reports and processes. The request group is associated with a security profile which defines the data a user can view, and is then assigned to a responsibility. It is also possible to set up reporting only request groups for users who access the database, but who are not permitted to change any of the records within the system.

For more information, see Setting up Standard Security.

Access to Multiple Business Groups using Standard Security

In Standard HRMS Security, you can grant users access to more than one business group within your enterprise. To do this, you must create security profiles and responsibilities and assign them to each additional business group. If a user’s responsibility is assigned to more than one business group, they will not be able to view data from more than one business group at any time.

Note: The HR: Cross Business Group Profile option enables users to view some limited information across all business groups within an enterprise. For more information, see HR: Cross Business Group Profile option.

Standard HRMS Security (Security Groups Disabled) is commonly used in organizations which operate within a single legislation and a single business group.

Important: After setting up Standard HRMS Security, you can switch to the Security Groups Enabled security model. You cannot, however, to revert back to Standard HRMS Security after this change has been made.

The Completed Standard HRMS Security Model

Security Groups Enabled Model

The main difference between the two security models is that the Security Groups Enabled model enables your enterprise to share security profiles and responsibilities between users and business groups. This reduces the set up time, and also increases the flexibility of this security model. The key to re-usability is the relationship between the security elements and the users that you create during the set up process.

Important: Once you have set up Security Groups Enabled security, you cannot revert to Standard HRMS Security.

Access to Multiple Security Groups using Security Groups Enabled Model

The Security Groups Enabled security model enables you to assign a single responsibility to more than one business group, and hence enable users to access records from numerous business groups, although users cannot view information from different business groups simultaneously.

To set up Security Groups Enabled security, you set the Enable Security Groups Profile option to Yes, and run the Enable Multiple Security Groups process. These steps in combination create a Security Group which has the same name as the business group from which it was created. For more information, see Security Groups.

Note: To make the administration of your security setup easy to maintain, it is recommended that you leave the names of the Security Groups the same as your business groups.

Like Standard HRMS Security, your enterprise must create Security Profiles for each distinct security grouping within your enterprise. Security Profiles function slightly differently in the Security Groups Enabled model than they do in Standard HRMS security. Rather than one security profile being assigned to one responsibility, Security Groups Enabled security enables your enterprise to assign numerous security profiles to a responsibility. For example, an HR Manager and an Assistant HR Manager may be able to access the same menus and windows, but may be able to view different data. The following example illustrates the benefits of this function.

Assigning Multiple Security Profiles to a Responsibility

Note: The limitation of this is that a user can only be assigned one Security Profile per responsibility.

The functionality of responsibilities is also enhanced in the Security Groups Enabled security model. Increasingly, users require access to the records in more than one business group. To accomplish this, you can assign a responsibility to multiple business groups when you use Security Groups Enabled. The records, forms and type of data a user can access will be the same in each of the business groups to which they have access.

Note: When a responsibility is assigned to more than one business group, the user can only view records from one business group at any time.

The ability to assign one responsibility to multiple business groups makes the set up of security quicker and more efficient.

Note: The HR: Cross Business Group Profile Option enables users to view some information across all business groups within an enterprise. For more information, see HR: Cross Business Group Profile option.

Assigning a Responsibility to Multiple Security Groups

As with Standard HRMS Security, you can set up a request group to restrict user access to reports and processes. The request group is associated with a responsibility which defines the data a user can view. It is also possible to set up reporting only request groups for users who access the database, but who are not permitted to change any of the records within the system.

Once your enterprise has defined the security profiles and responsibilities, you must assign them to the relevant security groups. The final stage is to assign users to this group of information. The example below illustrates how the final security set up may look within your enterprise.

For more information see Setting Up Security Groups Enabled Security.

The Completed Security Groups Enabled Model

Three distinct enterprise types can benefit from the functionality offered by the Security Groups Enabled model; Service Centers, Multinationals and SSHR enterprises. Of course, the simplified set up and maintenance is of benefit to any enterprise.

Typically, Service Centers create a new business group for each customer they serve. Furthermore, Service Centers only require one responsibility and security profile to enable users to access and change data within the system. As the Security Groups Enabled model enables sharing of security profiles and responsibilities, the security set up process for Service Centers becomes quicker and more efficient.

In the case of Multinational enterprises, it is common to create a business group for each country in which the enterprise operates, and for each legislation the enterprise uses. Using the Security Groups Enabled model enables users to share records and data across business groups and countries.

For enterprises that use SSHR within a global implementation, the advantages of using Security Groups Enabled include quicker set up and easier maintenance. An additional benefit is that transferring employees or employee information between business groups is simplified.

Security Groups (Security Groups Enabled Model Only)

When you use the Security Groups Enabled security model (formerly called Cross Business Group Responsibility security), a security group is automatically created for each business group when you run the Enable Multiple Security Group Process. Because security groups are tied to business groups by set up, partitioning data using this method is the same as partitioning data by business group. See: Setting Up Security Groups Enabled security.

Important: Security groups are only used if you have set up your enterprise using the Security Groups Enabled security model.

Security groups are the key component in Security Groups Enabled security. They enable you to set up one responsibility and link this to a number of different business groups.

Before you can start using this security model you ensure that HRMS is set up to use security groups. To do this you set the Enable Security Groups profile option to Yes and run the Enable Multiple Security Group process.

Important: You can change from Standard HRMS security to Security Groups Enabled security, however, you cannot switch from Security Groups Enabled security back to Standard HRMS security. See: Updating the Security Model.

Once you have set up your enterprise to use security groups, Oracle HRMS automatically creates a security group when you set up a business group. The security group has the same name as the business group. For example, if you create a business group called UK Headquarters, Oracle HRMS automatically creates a security group called UK Headquarters. The Setup Business Group, however, uses the predefined security group Standard.

Note: If you change the name of your business group, the security group name is not updated. To make the maintenance of your security setup easier, Oracle recommends that you leave the names of the security groups the same as the business groups from which they are created.

Using the Assign Security Profile window you link the user, responsibility and business group to a security profile. By entering a business group you are automatically linking the responsibility to the security group.

You then log on using the responsibility and security group pairing. As security groups are automatically linked to a business group, you can then view and manage the records for that business group.

When you log on, Oracle HRMS displays all the pairings you have created between business groups and responsibilities. You could have the same responsibility listed twice with different security groups and therefore business groups. By looking at the security group you can select the correct responsibility for the business group you want to access.

To ensure the integrity of your business data, you can only view records for one business group at any time. To view records from a different business group you must switch to an alternative responsibility and business group pairing.

Important: Security groups are automatically created for you when you use Oracle HRMS. Do not use the System Administrator’s Security Groups window to add security groups as these will not be linked to your business groups.

End-Dating Unwanted Responsibilities

When you first enable security groups and run the Enable Multiple Security Groups concurrent process, the process creates two sets of records for existing user/responsibility pairs:

• For each responsibility connected to a user it creates a record linking the user, the responsibility and the Standard security group.
  
• For each HRMSresponsibility connected to a user it creates a record linking the user, the responsibility, the security group associated with the business group, and the security profile.

If you are updating from Standard security, there may be many such records. For each existing user responsibility with a security group value of ‘Standard’, you need to decide whether or not the user requires access to the responsibility. Users who may need to update global lookup codes need access to the Standard security group.

In most cases, users will not require access to the Standard security group. In this case, enter an end date to remove access to the responsibility. This reduces the number of responsibilities the user sees on logging in, and prevents users from accidentally entering data into the wrong business group.

Note: By default, the Standard security group is associated with the Setup business group.

Example

If your user is set up with a responsibility called HRMS Manager you could link this to:

• UK Headquarters (business group)
  
• Scotland Operations (Security Profile)

Using the same responsibility (HRMS Manager), you could also link to a different business group:

• Canadian Headquarters (business group)
  
• Vancouver Operations (Security Profile)

Therefore, you only need to set up one responsibility (HRMS Manager) but you can enable two business groups (UK Headquarters and Canadian Headquarters).

When the business group UK Headquarters was set up, a security group UK Headquarters was automatically created. When you linked the business group to the user’s responsibility, the security group UK Headquarters would also be linked.

To view the records for business group UK headquarters you would select the HRMS Manager responsibility and the UK Headquarters security group.

If you then wanted to view the records for the Canadian Headquarters business group you would switch responsibility and security group pairing, selecting the same responsibility (HRMS Manager) and the Canadian Headquarters security group.

Categorizing Information By Security Groups

Important: You can only categorize information by security groups if you are using Security Groups Enabled security.

You can categorize the following information within your enterprise using security groups:

• Lookups
  Using the Application Utilities Lookups window you can set up lookups specifically for a security group. These lookups are only available to users who access the business group associated with the security group.
  See: Adding Lookup Types and Values.
  
• Concurrent Programs
  Using the Concurrent Parameters Program window you can enter a security group against a concurrent program, this creates a specific list of concurrent programs for a security group and therefore business group. When a user selects a concurrent program using the Submit Request window, they can select from the concurrent programs for their business group.

Note: You do not have to enter a security group against all the concurrent programs. Concurrent programs which are not linked to a security group display for all security groups/business groups.

See: Concurrent Parameters Program window, Oracle Applications System Administrator’s Guide.

Reporting Access

Oracle HRMS enables you to set up reporting users who can query and report on the information in the database, but cannot insert, update or delete information. Reporting users can use Oracle tools, or other tools connected to the Oracle database, to report on information. Regardless of the tools used to access the database, reporting users can only read information, they cannot update information.

Using Oracle HRMS you can set up similar security restrictions to users who can update, insert or delete information. This ensures reporting users can only query and report on appropriate records.

All secure users connect to the APPS ORACLE ID. This is created when the system is installed. However, for reporting users, you should create one or more new reporting user ORACLE IDs. By associating these with a restricted security profile you can control whose records a reporting user can access.

You can make any of your restricted security profiles available not only for regular users, but also for reporting users. The security profile restricts a reporting user’s access to employee records in exactly the same way as it limits regular users’ access.

Reporting users can see all the details about the records they can access. To restrict the access of what a reporting user can view you must use view-based accesses. To support this need of reporting users you can use third party reporting tools to create business views.

For information about how to set up database access without on-line access, see: Setting Up Reporting Users.

Security Processes

There are four system security processes:

• Enable Multiple Security Groups 
  Run this process when you first set up Security Groups Enabled security.
  
• Generate Secure User
  Run this process when you create a new security profile that references a reporting user.
  
• Security List Maintenance
  Run this process every night.

You run these processes using an HRMS responsibility from the Submit Request window.

• Grant Permissions to Roles
  This process is run automatically as part of the autoinstall process.

Enable Multiple Security Groups Process (HRSECGRP)

You must run the Enable Multiple Security Groups process if you set the Enable Security Groups profile option to Yes. This process must be run when:

• You set up Security Groups Enabled security for the first time to enable HRMS to use multiple security group features.
  
• You change from Standard HRMS security to Security Groups Enabled security. This ensures that all your existing business groups have security groups and all the multiple security group features are enabled.

Note: To avoid errors when running the Enable Multiple Security Groups process, make sure that you  set the Enable Security Groups profile option to Yes at the Application level.

Generate Secure User Process (SECGEN)

This process grants permissions to new reporting users. It grants the “hr_reporting_user” role to the REPORTING_ORACLE_USERNAME specified in the security profile.

Run this process when you have created a new security profile that references a reporting user. In the Submit Requests window, select the name of the new security profile. This is the only parameter for the process.

Security List Maintenance Process (PERSLM)

This process maintains the lists of organizations, positions, employees, contingent workers and applicants that security profile holders can access. You should schedule it to run every night to take account of changes made during the day to security profiles, organization and position structures, and person records. If a disruption, such as a power cut, occurs while the process is running, you can manually restart it from the Submit Request window.

Note: The PERSLM process replaces the earlier LISTGEN and GLISTGEN processes.

See also Running the Security List Maintenance Process

Important: The Security List Maintenance process should normally run when there are no users logged on to the system. Users attached while this process is running may experience unexpected results; for example, additional employees may become visible or previously visible employees may disappear from view.

Grant Permissions To Roles Process (ROLEGEN)

All reporting users in the system share access to a set of public synonyms for tables and views. Reporting users are granted permissions to make them usable. The Grant Permissions To Roles process creates these public synonyms and grants permissions to them.

Important: The Grant Permissions to Roles process is unrelated to setting up workflow roles for Oracle products that support security by workflow.

This process runs automatically as part of the autoinstall process when you install HR, or when you upgrade the system.

The process creates public synonyms for each of the required HR objects and then grants SELECT permissions to the role ‘hr_reporting_user’. Permissions are not granted on the secured tables, but only on the secure views of those tables. All permissions previously granted to the role are revoked before the new grants are made. This ensures that the correct grants exist for the valid HR objects.

Setting Up Standard HRMS Security

Use the following setup steps if your enterprise sets up a different responsibility for each business group.

To set up users for Standard HRMS security:

1. Ensure that the Enable Security Groups profile option is set to No at site and application level, using the System Profile Values window.
   If this option is set to Yes then you are not using Standard HRMS security.
   See: System Profile Values, Oracle Applications System Administrator’s Guide.
2. Define a Security Profile 
   Note: For each restricted security profile you create that references a reporting user, you must run the Generate Secure User (SECGEN) process. This is a one-off process that is not required for view-all security profiles.
3. Ensure that the required functions or menus are set up. 
   This is required for the responsibility. For menu functions calling configured forms or task flows, you must enter a parameter in the Parameter field of the Form Functions window.
   See: Defining Menus
   See: Set Up Menus
4. Ensure that the required request group is set up.
   You can define the groups of standard reports and processes that a user can run from the Submit a New Request window. Every responsibility can have access to one request group.
   Use the Request Groups window.
   See: Request Groups window, Oracle Applications System Administrator’s Guide
5. Define a responsibility using the Responsibility window.
   See: Responsibilities Window, Oracle Applications System Administrator’s Guide
6. Set the HR User Profile Options for the new responsibility using the System Profile Values window. You must set up the: 
   
   • HR: User Type
     Use this profile option to limit field access on windows shared between Oracle Human Resources and Oracle Payroll.
     
   • HR:Security Profile
     Enter the security profile for the responsibility. This must be set up at responsibility level, otherwise the default view-all security profile is used. Using Standard HRMS security you can only set up one security profile for a responsibility.
     
   • HR:Cross Business Group Profile
     This option enables you to view some information across all business groups within your enterprise.
     You can set also set up other User Profile Options.
   See: System Profile Values Window, Oracle Applications System Administrator’s Guide
7. Create the username and password using the User window. 
   Link the user to as many responsibilities as they need using the User window. 
   Important: Do not use the HRMS Assign Security Profile window if you are setting up Standard HRMS security.
   See: Users Window, Oracle Applications System Administrator’s Guide
8. Run system security process using the Submit Request window:
   
   • Security List Maintenance
     Ensure this process is run every night.
   See: Running the Security List Maintenance Process

Setting Up Security Groups Enabled Security

Use the following setup steps if your enterprise wants to enable many business groups for one responsibility.

Note: You only need to perform steps 1 and 2 when you first implement Oracle HRMS security. You can perform the other steps at any time.

You can update your security model from Standard HRMS Security to Security Groups Enabled security by following these steps.

Important: Once you have changed to Security Groups Enabled Security you cannot revert to the Standard Security model.

To set up users for Security Groups Enabled Security:

1. Set the Enable Security Groups Profile Option using the System Profile Values window.
   Ensure the Enable Security Groups profile option is set to Yes at the application level for Oracle Human Resources.
   Note: If this option is set to No then you are not using Security Groups Enabled security. 
   See: System Profile Values, Oracle Applications System Administrator’s Guide.
2. Run the Enable Multiple Security Group Process using the Submit Request window.
   You must run the Enable Multiple Security Group process to set up Oracle HRMS to use security groups.
   See: Submitting a Request, Oracle Applications System Administrator’s Guide
   Warning: The creation of security groups is more complex with Oracle HRMS 11.5.10 and later releases. For this reason, the Enable Multiple Security Group process may appear slow, particularly if you have a large number of business groups. 
   The Enable Multiple Security Group process sets the Enable Security Groups profile option to Yes for all HRMS applications. We strongly recommend that you do not change the value of this profile option to another value.
3. Define a Security Profile.
   Note: For each restricted security profile you create that references a reporting user, you must run the Generate Secure User (SECGEN) process. This is a one off process that is not required for view all security profiles.
4. Ensure that the functions or menus you require are set up.
   This is required for the responsibility. For menu functions calling configured forms or task flows, you must enter a parameter in the Parameter field of the Form Functions window.
   See: Set Up Menus.
   See: Defining Menus.
5. Ensure that the request group you require is set up.
   You can define the groups of standard reports and processes that a user can run from the Submit a New Request window. Every responsibility can have access to one request group.
   Use the Request Group window.
   See: Request Group window, Oracle Applications System Administrator’s Guide
6. Define a responsibility using the Responsibility window.
   See: Responsibility Window, Oracle Applications System Administrator’s Guide
7. Set the HR User Profile Options for the new responsibility using the System Profile Values window. You must set up the HR: User Type option.
   You can also set the HR:Cross Business Group Profile option. This enables you to view some information across all business groups within your enterprise. See HR:Cross Business Group Profile option for more information.
   Note: For Security Groups Enabled security donotset up or amend the HR:Security Profile profile option or the HR: Business Group profile option using the System Profile Values window. To set up or change this profile option use the Assign Security Profile window.
   You can set also set up other User Profile Options.
   See: System Profile Values Window, Oracle Applications System Administrator’s Guide
8. Create usernames and passwords using the User window. 
   Important: Do not link responsibilities and security groups (business groups) to users in this window. Instead, use the Assign Security Profile window. If you do enter a responsibility and security group in this window, you still need to use the Assign Security Profile window, to link your user to a responsibility and security profile. If you do not use the Assign Security Profile window, the default view-all security profile is used and your user will be able to see all records in the business group. 
   See: Users Window, Oracle Applications System Administrator’s Guide
9. End-date unwanted user responsibilities linked to Standard security group
   When you first enable security groups and run the Enable Multiple Security Groups concurrent process, the process creates two sets of records for existing user/responsibility pairs:
   
   • For each responsibility connected to a user it creates a record linking the user, the responsibility and the Standard security group.
     
   • For each HRMSresponsibility connected to a user it creates a record linking the user, the responsibility, the security group associated with the business group, and the security profile.
     If you are updating from Standard security, there may be many such records. For each existing user responsibility with a security group value of ‘Standard’, decide whether the user requires access to the responsibility. Users who may need to update global lookup codes need access to the Standard security group.
     In most cases, users will not require access to the Standard security group. In this case, enter an end date to remove access to the responsibility. This reduces the number of responsibilities the user sees on logging in, and prevents users from accidentally entering data into the wrong business group.
   Note: By default, the Standard security group is associated with the Setup business group.
   Use the Users window.
   See: Users Window, Oracle Applications System Administrator’s Guide
10. Assign Security Profiles.
    Associate a security profile with a user, responsibility and business group using the Assign Security Profile window.
11. Run system security process using the Submit Request window:
    
    • Security List Maintenance
      Ensure this process is run every night.
      See: Running the Security List Maintenance Process

Setting Up Security for Applications Using Some HRMS Windows

If you are setting up an Oracle application that uses HRMS windows (such as Organization or Position), you need to set up some features of HRMS security.

Note: If you have licensed Oracle HRMS, do not follow these setup steps. Instead, follow the steps in Implementing Oracle HRMS.

Using the following procedure you can either set up a responsibility that can view all records in the Business Group, or restrict access to the records for selected organizations or positions. You can also set up organization security for Financials and Manufacturing business views.

Organization Security for Financials and Manufacturing Business Views

You can set up security for Oracle Financials and Manufacturing applications that use organizations and organization hierarchies in their business views.

To do this, you create a single security profile that secures data either by single operating unit or by operating unit and inventory organizations, as required. You must also set the MO:Security Profile profile option at site or application level, to point to this new security profile.

To establish multi-operating unit access for some business view users, you can create for each type of user a security profile that secures organizations by organization hierarchy, using the security profile functionality. You can then set the MO:Security Profile option at responsibility level for these users.

The show_bis_record function secures data according to the definition of the security profile that is referenced by the MO:Security Profile profile option. If this profile option is not set, the HR:Security Profile profile option is used. This function is called by financials and manufacturing business views.

Single Operating Unit Security

In the Organization Security tab of the Security Profile window, select the Secure organizations by single operating unit option from the Security Type poplist. The operating unit is determined using the operating unit specified in the MO:Operating Unit profile option.

Single Operating Unit Plus Inventory Organizations

In the Organization Security tab of the Security Profile window, select the Secure organizations by operating unit and inventory organizations option from the poplist. The operating unit is determined using the operating unit specified in the MO:Operating Unit profile option. The inventory organizations you wish to include must exist within this operating unit.

Impact on Security Implementations

Financial and manufacturing business view users who have not created security profiles have unrestricted access to their data.

Financial and manufacturing business view users can secure their business view data by security profiles identified by the HR:Security Profile profile option, as long as they have not set the MO:Security Profile profile option. If this has been set, they must modify their security setup to reflect the fact that the financial and manufacturing business views secure data using the MO:Security Profile profile option.

HRMS security is not affected by these options. The HRMS business views and forms secure data according to the setting of the HR:Security Profile profile option.

To set up security

1. If you are setting up a restricted access responsibility, create a restricted security profile to define the organizations or positions the responsibility can access.
   Note: Ensure your Application supports restricted access security. Not all Oracle Applications support this type of security. 
   If you are setting up a responsibility which can view all the records in the Business Group, you do not need to set up a security profile. 
   Note: A view-all security profile is automatically created when you set up a Business Group. The view-all security profile always has the same name as the Business Group.
   See: Defining a Security Profile
2. Define a responsibility using the Responsibility window.
   See: Responsibilities Window, Oracle E-Business Suite System Administrator’s Guide – Security
3. Select a security profile for the new responsibility. 
   In the System Profile Values window, enter a security profile at the responsibility level for the HR:Security Profile profile option.
4. Create a new user and link the user to a responsibility using the User window.
   See: Users Window, Oracle E-Business Suite System Administrator’s Guide – Security
5. If you are setting up restricted access security, run the Security List Maintenance Process (PERSLM) from the Submit a New Request Window. If you are setting up view-all security you do not need to run the Security List Maintenance process.
   This process maintains the list of organizations, positions, employees and applicants that security profile holders can access. You should schedule it to run every night to take account of changes made during the day.
   See: Running Reports and Programs, Oracle E-Business Suite User’s Guide

Setting Up Reporting Users

Reporting users do not have online access to the database through system forms. They use reporting tools to prepare reports on the information their security profiles grant.

All secure users connect to the APPS ORACLE ID. This is created when the system is installed. However, for reporting users, you should create one or more new reporting user ORACLE IDs and associate each with a restricted security profile. Only users that have been registered as Restricted Oracle Users are available for selection as reporting users in the Security Profile windows.

The first step in this procedure is the job of the ORACLE database administrator. The other steps are normally completed by the system administrator.

To set up a new reporting user

1. Create a new reporting user ORACLE ID.
   
2. Register the new ORACLE ID with Application Object Library using the Oracle Users window, selecting Restricted in the Privilege field.
   
3. Define a security profile for the new ORACLE ID.
   See: Defining a Security Profile
   
4. Run the HR security processes using the Generate Secure User Process.
   See: Running Reports and Programs, Oracle E-Business Suite User’s Guide
   

Defining a Context for Mass Actions

The Contexts window determines what information the user can view, enter, and change based on the Application, Legislation, and Responsibility.

A predefined global Context contains the default attribution that appear on the forms. When you create a new Context, these attributes serve as a basis for selecting which attributes to include as display, change, and criteria attributes.

The predefined global Context does not specify values for Application, Legislation, or Responsibility.   You can restrict who can process mass actions by specifying these attributes. The system always applies the most defined Context, so as soon as you define these fields, the system applies the new Context instead of the global one.

You define a new context in the Contexts window.

To define a Context

1. Choose New from the File menu.
   
2. In the Context field, enter a name.
   
3. In the Transaction Name field, choose the Transaction Category to affect.
   
4. In the Application field, select an application.
   
5. Optionally, choose one or more of the following fields to restrict a user’s ability to view and change data: 
   
   • In the Legislation field, select a Legislation
     
   • In the Responsibility field, select a Responsibility
6. Choose the Find Attributes button.
   The system displays the attributes from the global Context window on the Display and Change List tabbed regions.
   
7. Choose the Display tab and select those items to display on the Columns portion of the transaction template.
   
8. Choose the Change List tab and select those items to display for the Change List values.
   
9. Choose the Criteria tab and select the items you want to have appear on the Other Criteria list of values in Selection Criteria block on the Original tab.
   
10. Choose the Compile button to save your work and compile the flexfield definitions. 
    
11. Save your work.
    

Setting Up the Security Performance Enhancement Feature

Typically, most of the Oracle HRMS products use the security mechanism that Oracle HRMS provides. Defining which records and information users can access is fundamental to HRMS security. To enhance product performance when person security evaluation happens during processing of voluminous data, Oracle HRMS provides the security performance enhancement feature. You can set up this feature, if required, based on your business needs.

To set up the security performance enhancement feature

Complete the following steps to set up the security performance enhancement feature.

1. Run the Synchronize Security Performance Tables process to synchronize the PER_ALL_ASSIGNMENTS_F_PERF table with the PER_ALL_ASSIGNMENT_F table. 
   The PER_ALL_ASSIGNMENTS_F is the base table, which Oracle HRMS uses to evaluate person security. The PER_ALL_ASSIGNMENTS_F_PERF table is a performance table and includes the following columns from the PER_ALL_ASSIGNMENTS_F table:
   
   1. ASSIGNMENT_ID
      
   2. EFFECTIVE_START_DATE
      
   3. EFFECTIVE_END_DATE
      
   4. PERSON_ID
      
   5. POSITION_ID
      
   6. PAYROLL_ID
      
   7. ORGANIZATION_ID
      
   8. SUPERVISOR_ID
      
   9. SUPERVISOR_ASSIGNMENT_ID
      
   10. BUSINESS_GROUP_ID
       
   11. ASSIGNMENT_TYPE
       
   12. ASSIGNMENT_STATUS_TYPE_ID
       
   13. PRIMARY_FLAG
   See: Running the Synchronize Security Performance Tables Process
   
2. Make sure that the PER_ASG_PERF_TRG trigger on the PER_ALL_ASSIGNMENTS_F table is enabled all the time as this trigger is responsible for the incremental refresh of the PER_ALL_ASSIGNMENTS_F_PERF table whenever there is a DML operation on the PER_ALL_ASSIGNMENTS_F table.
   
3. Set the HR: Security Performance Enhancer profile option at the responsibility level, so that Oracle HRMS retrieves information from the assignment records in the PER_ALL_ASSIGNMENTS_F_PERF table during person security evaluation. This ensures that the person security data retrieval is faster.
   

Troubleshooting security performance enhancement issues

If you encounter any security performance enhancement issues, then complete the following steps:

1. Run the Synchronize Security Performance Tables process:
   Verify if there is any difference in the row count between PER_ALL_ASSIGNMENTS_F and PER_ALL_ASSIGNMENTS_F_PERF tables. If there is any difference between the two tables, then run the Synchronize Security Performance Tables process to synchronize data in the two tables.
   
2. Reset the HR: Security Performance Enhancer profile option:
   If the difference in the row count between PER_ALL_ASSIGNMENTS_F and PER_ALL_ASSIGNMENTS_F_PERF tables still exists after you run the Synchronize Security Performance Tables process, then reset the HR: Security Performance Enhancer profile option to Null and retest the issue. 
   

You cannot use the security performance enhancement feature if your enterprise uses custom security.  When the system administrator creates custom security mechanism, the administrator can make use of any of the columns in the PER_ALL_ASSIGNMENTS_F table to define security restrictions. However, the PER_ALL_ASSIGNMENTS_F_PERF table contains data from only 13 columns of the PER_ALL_ASSIGNMENTS_F base table. See list of columns. If you use any column other than the columns in the PER_ALL_ASSIGNMENTS_F_PERF table, set the HR: Security Performance Enhancer profile option and define custom security, then this feature as well as the general Oracle HRMS security mechanism will not work.

Running the Synchronize Security Performance Tables Process

The Synchronize Security Performance Tables is a process which deletes the rows from the PER_ALL_ASSIGNMENTS_F_PERF performance table and inserts data from the PER_ALL_ASSIGNMENTS_F base table to the PER_ALL_ASSIGNMENTS_F_PERF table. Run this process if you want to use the security performance enhancement feature. For more information, see: Setting Up the Security Performance Enhancement Feature

You run this process from the Submit Request window.

Prerequisites

• This process is not delivered in any request sets or groups. To use the process, you must add the process to a request group and, if applicable, a request set.

To run the Synchronize Security Performance Tables process

1. In the Name field, select Synchronize Security Performance Tables.
   
2. Select ASG_PERF, which is the Assignment Performance Table (PER_ALL_ASSIGNMENTS_F_PERF) table.
   
3. Click OK and submit the process.
   

Verify if there is any difference in the row count between PER_ALL_ASSIGNMENTS_F and PER_ALL_ASSIGNMENTS_F_PERF tables. If there is any difference between the two tables, then rerun the Synchronize Security Performance Tables process to synchronize data in the two tables.

Security Profiles

Security Profiles

The security profile determines which applicant, employee, contingent worker and other person type records are available to holders of the responsibility the profile is linked to.

If you are using HRMS Standard security, you link a security profile to one responsibility using the HR:Security Profile profile option.

If you are using Security Groups Enabled security, you link a security profile to the user’s responsibility and business group using the Assign Security Profile window. You can also link more than one security profile to a responsibility, as long as the user is different. This saves you setting up a new responsibility for each security profile you use.

Note: If you are using the Security Groups Enabled security model you must not use the HR:Security Profile profile option. This is automatically set up when you assign security profiles using the Assign Security Profile window.

See also Defining a Security Profile

Restricting Access to Records

You set up a security profile by identifying records of employees, applicants, contingent workers, and candidates in the system which you want users to be able to access. You identify the records by selecting work structures or other criteria in the application to which employees, applicants, contingent workers, or candidates are attached. For example, you could give users access only to the records of employees, applicants, contingent workers, or candidates in a single organization.

You can also create restrictions on records with a person type of “Other”. This includes contacts for employees or applicants, and any other people with a person type in the category of “Other”. You do this using the “View Contacts” option.

You can combine different types of restriction to create a set of rules giving exactly the security access permissions you require.

When you create a business group a view-all security profile is automatically created. This has the same name as the business group. The security profile provides access to all employee, contingent worker, andapplicant records in the business group. The system administrator links this view-all profile to users who are setting up the system. They in turn can set up security for other users.

The criteria you can use to identify records are:

• Internal organizations and organization hierarchies
  
• Positions and position hierarchies
  
• Payrolls
  
• Supervisors and supervisor hierarchies
  
• Custom restrictions
  
• Assignments

Tip: Oracle recommends that you use either a supervisor or position hierarchy for Self-Service Human Resources (SSHR).

For more information on hierarchies in SSHR, see: People in Hierarchy, My List, and Search Pages, Oracle SSHR Deploy Self-Service Capability Guide.

InternalOrganizations and Organization Hierarchies

Organizations include structures like departments, sections, groups and teams. You can restrict access to a single organization, a list of organizations, or an organization hierarchy. If you restrict on an organization hierarchy, you can exclude specific organizations that are in the hierarchy, or add other organizations that are not in the hierarchy.

Positions and Position Hierarchies

Positions are jobs performed within specified organizations. The position is derived from an organization and a job, for example, you may have a position of Shipping Clerk associated with the organization Shipping and the job Clerk.You can define security restrictions based on a position hierarchy.

Payrolls

You can restrict access to employee records by payroll.For example, you can give payroll staff who work on the payroll at a particular location access to records of employees on this payroll only.

Controlling security by payroll assignment limits the employee records users can see and update on employee-related windows, such as those for employee information, and element entry.

Of course, if an employee assignment does not include a payroll, payroll security cannot apply to this assignment. Payroll security also applies to applicants if they are assigned to a payroll.

Note: Payroll security is not available for contingent workers since they are not assigned to a payroll.

The windows for compensation definition are unrelated to any particular employee records or payroll assignments. Therefore limiting access by payroll does not affect users’ access to these windows.

Supervisors and Supervisor Hierarchies

The supervisor for an employee, applicant or contingent worker is the person identified in the Supervisor field in HRMS applications. Supervisor profiles are dynamic, in that they do not have to specify a particular person or hierarchy level. You can therefore set up a single security profile and use it for multiple users, who will each be able to access a different set of records depending on their own location in the hierarchy.

Note: If you choose to use supervisor hierarchy, you must also set the HR: Supervisor Hierarchy Usage profile option. This profile defines how supervisor hierarchies are built. You can choose whether to create person-based or assignment-based supervisor hierarchies.

Person-based supervisor hierarchy

A person-based supervisor hierarchy is a hierarchy based on a person’s supervisor and direct reports.

Assignment-based supervisor hierarchy

As an alternative to the person hierarchy, you can choose to build a hierarchy based on the supervisor assignment. In this case, you also specify the supervisor assignment number for a person and the security processes use this assignment to generate an assignment-based supervisor hierarchy. As for the other supervisor-based hierarchy, the assignment-based hierarchy is dynamic and this security profile can be used for multiple users.

Note: When you set up security based on supervisor hierarchies, the list of employees visible to a user is usually generated at the start of the session. Therefore, for profiles that only restrict access by supervisor there is usually no need to run the Security List Maintenance process. However, for supervisors with a large number of subordinates (for example, at higher management levels) this may result in a delay in generating the list. You can improve performance by limiting the number of hierarchy levels a supervisor can access or by using the Static Lists functionality to store the security permissions in a list.

For more information, see Static Lists.

Alternatively, for the highest levels of management, consider setting up security using organization hierarchies.

Custom Restrictions

You can set up your own restrictions using SQL statements (for example, you might want to create a restriction allowing users access only to temporary part-time employees). Your custom restriction statements are automatically validated by the system. Valid restrictions are incorporated in the security profile, further restricting the list of employees, applicants and contingent workers specified using any of the other methods mentioned above.

Since you are defining additional restrictions using SQL, you need to ensure your SQL statements are tuned for performance. Otherwise, they will have an adverse effect on the time it takes to execute the Security List Maintenance process.

Important: Custom restrictions directly restrict employees, applicants and contingent workers only; you cannot create custom restrictions on people with a system person type of Other. However, if you add custom restrictions on employees, applicants or contingent workers, related people with a system person type of Other are restricted according to the setting of the “View Contacts” option.

As for other forms of security set-up, you can choose whether to enable user-based custom security. This means that Oracle HRMS uses your custom rules to evaluate security permissions for a user when that user logs on to the HR application. The alternative is to use static lists to store the security information for users or to run the Security List Maintenance process to regularly update the permissions.

Assignment-Level Security

Assignment-level security enables you to restrict security access based on individual assignments. This means that the security processes evaluate permissions on an individual assignment basis, rather than displaying all assignments if a manager has access to one assignment.

For more information, see: Assignment-Level Security.

User-Based Security

With user-based security, the application evaluates the security rules and permissions for the user logged on to the application. For example, if Bob Wright logs on to Self-Service Human Resources (SSHR), his access to organizations, positions, people, and assignments is based on his personal assignment details. The advantage of user-based security is that you can use one user-based security profile for multiple users. User-based security is available for security profiles based on organizations, positions, and supervisors, and can also be used in conjunction with custom security.

HR users can access ex-employee and future-dated records. For more information, see: Access to Ex-Employee and Future-Dated Employee Records

For more information on user-based security, see the individual sections in Defining a Security Profile.

Static Lists

Static lists enable you to choose whether to assess security permissions for a user when that user logs on (dynamically) or whether to store the permissions in static lists. The advantage of using static lists is that Oracle HRMS can quickly retrieve the permissions when the user logs on as the data is already available. A typical use of static lists may be for a senior manager who has access to many people.

When a user is in the static list, security permissions remain frozen until the next time you run the Security List Maintenance process. You can choose how often to run the Security List Maintenance process and schedule the process to run frequently if users’ permissions are likely to change frequently.

A static list can contain any number of users. You can run the Security List Maintenance process for all users in the static list or use the Process in Next Run option on the Static Lists tab of the Security Profile window to select a specific user or group of users. You use this option in conjunction with the Security List Maintenance parameters; you can run the process for either all users in the static list or only users you select using the Process in Next Run option. By selecting specific users for inclusion in the run, you reduce the time and resources required to run the Security List Maintenance process.

See: Running the Security List Maintenance Process

The choice of whether to use static lists instead of dynamic security assessments depends on several factors, including:

• If slow system performance is unacceptable at sign-on, you can reduce the processing requirement at sign-on by using static lists. Static lists can be particularly useful in the case of a top manager who has a large number of subordinate employees or organizations, for example. In this case, the process to evaluate security permissions may be lengthy at sign-on. 
  
• Static lists require additional maintenance to run the process. In addition, the static lists stores details of every person that the user included in the static list can access so if you include several users in a static list, you may experience an increase in data for processing and may need to consider running the process for selected users only.
  
• The other factors above become more significant as the size of an organization increases. Large numbers of users logging on to Oracle HRMS at the same time would result in a huge processing requirement at the point of sign-on. In this case, it may be advisable to add users most affected by sign-on issues to the static lists.

Global Security Profiles

You can create global security profiles that enable users to work on organizations in multiple business groups.

You do this by setting up a global hierarchy, which can contain organizations from any business group on your database, and associating it with a global security profile. This enables you to create a security hierarchy that gives users access to organizations across business groups.

If you want to read more information about organization hierarchies, see: Organization Hierarchies, Oracle HRMS Enterprise and Workforce Management Guide

If you use the Oracle HRMS Forms Interface, you cannot access data across business groups using one responsibility, even if you associate a global security profile to your responsibility. Your access is limited to organizations in the business group defined in the HR:Business Group profile option. However, you can use people management templates to query and update worker information across business groups.

Access to Ex-Employee and Future Dated Employee Records

If you use user-based security profiles either based on organization, position, or custom security, then you can enable HR users to access ex-employee and future-dated employee records using the HR: Access Non-Current Employee Data profile option. If you enable this profile option, then HR users can access ex-employee records, for example, to manage retirement benefits. HR users can update future dated records.

Note: The HR: Access Non-Current Employee Data profile option does not apply to security profiles based on the supervisor hierarchy.

See: User Profiles

Related Topics

Security Processes

Running the Security List Maintenance Process

Assignment-Level Security

The security features in Oracle HRMS enable you to restrict security access based on individual assignments. The security processes evaluate permissions on an assignment-by-assignment basis, rather than displaying all assignments if a manager has access to any assignment.

For example, without assignment-level security, a manager with access to an employee’s primary assignment would also have access to the employee’s other assignments even though the supervisor for the other assignments may be a different manager. To allow supervisors to view only the relevant employees and assignments, you can enable assignment-level security in the Security Profile window. You use this functionality in conjunction with your security profile settings (for example, organization, position, supervisor security).

The following examples show how a manager’s access to person records differs when assignment-level security is enabled and when it is disabled for a supervisor hierarchy, organization hierarchy, and position hierarchy.

Supervisor Hierarchies and Assignment-Level Security

The graphic below shows the direct reports for Sam Taylor and Sally Jones. The subsequent examples show how the managers’ access to the direct reports varies with the different security configurations.

Supervisor Hierarchy

Example 1: Assignment-Based Supervisor Hierarchy (No Assignment-Level Security)

If you set up a supervisor hierarchy that is based on the supervisor assignment, Sam can see the direct report for Bob’s first assignment (Jane). Because there is no assignment-level security, Sam can also see Bob’s second assignment, however, Sam cannot access the direct reports for the second assignment. Sally Jones can see Bob’s first assignment but cannot see the direct reports for this assignment (Jane). The following graphic illustrates the new hierarchy for Sam Taylor:

Assignment-Based Hierarchy for Sam Taylor (No Assignment-Level Security)

Example 2: Assignment-Based Supervisor Hierarchy (Assignment-Level Security)

With assignment-level security, Sam can only see Bob’s first assignment and the direct reports for this assignment (Jane). Sally can see Bob’s second assignment and Maria’s assignment and the direct reports for these assignments. The following graphic illustrates the hierarchy with assignment-level security for Sam:

Assignment-Based Hierarchy with Assignment-Level Security

Note: If you are using an assignment-based hierarchy, it is advisable to use assignment-level security.

Organization Hierarchies and Assignment-Level Security

The graphic below shows two organization hierarchies. Within the first hierarchy (Eastern Region Sales) there is an employee with multiple assignments. The subsequent examples show how the hierarchy changes with assignment-level security disabled and enabled.

Organization Hierarchy

Organization Hierarchy (No Assignment-Level Security)

In this situation, Sam can see the people within the Accounts and Presales organizations. He can also see the people in organizations below Presales in the organization hierarchy (Team 1 and Team 2). Bob Wright has a second assignment in a different organization (Western Region Sales/Presales). Because assignment-level security is disabled, Sam can see this assignment (if a manager can access one assignment, he can access them all). Sam cannot see the organizations below the organization for Bob’s second assignment. The following graphic illustrates the hierarchy without assignment-level security for Sam Taylor:

Organization Hierarchy (No Assignment-Level Security)

Organization Hierarchy (With Assignment-Level Security)

In this situation, Sam can see all people within the Accounts and Presales organizations. However, Sam cannot see Bob’s second assignment (Western Region Sales/Presales) because the organization for the second assignment is not within the organization hierarchy to which Sam has access. The following graphic illustrates the hierarchy with assignment-level security for Sam Taylor:

Organization Hierarchy (With Assignment-Level Security)

Position Hierarchies

The graphic above shows two position hierarchies. Within the first hierarchy (Sales Research Director) there is an employee with multiple assignments. The following examples show how the hierarchy changes with assignment-level security disabled and enabled.

Position Hierarchy (No Assignment-Level Security)

In this situation, Tom can see the position below him in the hierarchy (Associate Sales Research Director). He can also see the reporting positions (Sales Research Specialists and Sales Research Technical Support Staff). Helen Richie has a second assignment for a different position (Regional Sales Director). Because assignment-level security is disabled, Tom can see this assignment (if a manager can access one assignment, he can access them all). Tom cannot see the positions below the position for Helen’s second assignment. The following graphic illustrates the hierarchy without assignment-level security for Tom Yorke:

Position Hierarchy (No Assignment-Level Security)

Position Hierarchy (With Assignment-Level Security)

In this situation, Tom can see the position below him in the hierarchy (Associate Sales Research Director). However, Tom cannot see Helen’s second assignment (Regional Sales Director) because the position for the second assignment is not within the position hierarchy to which Tom has access. The following graphic illustrates the hierarchy with assignment-level security for Tom Yorke:

Position Hierarchy (With Assignment-Level Security)

Implementing Assignment-Level Security

You enable assignment-level security in the Security Profiles window. To enable assignment-level security, select the Restrict on Individual Assignments option.

For more information, see: Defining a Security Profile

Assignment-level security is available for several areas of Oracle HRMS. The areas that currently support assignment-level security are:

• Self-Service Human Resources (SSHR)
  
• The following Oracle HRMS forms:
  
  • Combined Person and Assignment
    (PERWSHRG)
    
  • Enter Assignment (PERWSEMA)
    
  • People Management (PERWSQHM)
    
  • Define Assignment Extra Info (PERWSAEI)
    
  • View Benefits (PERWSVBI)
    
  • View Salary History (PERWSSLH)
    
  • Salary Review (PERWSEPY)
    
  • View Worker Assignment History (PERWSASH)
    
  • Assignments Folder (PERWSFAS)
• The following Oracle Payroll forms:
  
  • View Employee Run Result History (PAYWIELH)
    
  • Payroll and Assignment Processes (PAYWSACT)
    
  • Run QuickPay (PAYWSRQP)
    
  • Batch Element Entry (PAYWSQEE)
    
  • View Element Entry History for Employee (PAYWIEEH) 
    
  • List Employees by Element (PAYWSLEE)
    
  • Element Entry (PAYWSMEE)
    
  • Adjust Balances (PAYWSABL)
    
  • Pay Method (PAYWSEPM)
    
  • Irish P45 Form (PAYIEP45)
    
  • Irish SOE Form (PAYIESOE)
    
  • Reverse Payroll Run (PAYWSRPR)
    
  • Irish Tax Information (PAYIETAX)

Security Profiles by Supervisor Hierarchy

You can set up a security profile that permits access to a supervisor hierarchy. This means that when a manager logs on to Oracle HRMS, the application uses assignment or supervisor attributes to build a person tree with the manager at the top level. The person tree shows the direct reports for the manager and also any direct reports at lower levels of the hierarchy to which the manager has access.

The structure of the person tree depends on whether you are using an assignment-based or person-based supervisor security profile. The following examples highlight the differences between the two types of supervisor security:

Supervisor Hierarchies

Person-Based Supervisor Hierarchy

This type of security uses the Supervisor field in HRMS applications to generate a supervisor hierarchy. When a manager logs on to the HRMS application, the application assesses security permissions for the manager (user) and builds a hierarchy showing the manager’s direct reports and, if applicable, additional subordinate levels of employees. In this case, a manager can see all assignments for the direct reports. In the example, Sam Taylor can see both assignments for Bob Wright (assignments 1 and 2) and both direct reports for these assignments (Jane Lewis and Tom Acland).

Assignment-Based Supervisor Hierarchy

This type of security also uses the Supervisor field in HRMS applications but when the user enters the supervisor information, he or she can also select a particular assignment for the supervisor. When the supervisor logs on to Oracle HRMS or Oracle SSHR, the supervisor hierarchy is based on the supervisor’s assignment.

Note: You should only use an assignment-based supervisor hierarchy if you have enabled multiple assignments in your organization.

In the example, Sam Taylor’s access to person records depends on whether assignment-level security is enabled. If it is enabled, Sam can only access the records for Bob Wright’s first assignment and direct report. If assignment-level security is not enabled, Sam can access the records for both of Bob’s assignments and also for the direct report for the first assignment.

For more information, see Assignment-Level Security in Security Profiles.

HR: Supervisor Hierarchy Usage Profile Option

You use this profile option to specify the behavior of the supervisor hierarchy in HRMS applications by specifying whether the supervisor hierarchy is assignment or person-based.

Security Profiles by Organization and Organization Hierarchy

To set up a security profile that permits access to employee records of certain organizations only, you make use of organization hierarchies. You can build any number of additional hierarchies to meet your security requirements. There are two ways of doing this: either with or without user-based security.

For example, suppose you build this Sales Organization hierarchy:

Sales Organization Hierarchy

Without User-Based Security

You can create a security profile that permits access to employee records throughout the sales organization. This profile references the Sales Organization hierarchy. It names the Sales Department as the highest organization in the hierarchy through which profile holders have access to employee records.

Next, you want the directors of the two sales regions to have access to all employee records in their region only. You create Eastern and Western Sales Director security profiles. These profiles also reference the Sales hierarchy. But, they name the Eastern and Western Regions, respectively, as the top organizations for these profiles’ access to employee records.

When you name an organization as the top organization, you specify whether it is inclusive or not. You must include the top organization if you want holders of the profile to access records of people assigned to the top organization.

With User-Based Security

If you are using user-based security, you can choose to use the organization linked to the user’s assignment as the top organization. The top organization is then determined dynamically when the user logs on or when the Security List Maintenance process is run. To illustrate the advantage of using user-based security in this way, take the above example. Instead of having to create two security profiles so that the two regional sales directors can only access the records for the employees in their regions, you would only need to create one security profile which would identify the top organization based on the user’s assignment. In the example, the security process would identify that the top organization for one director is Eastern Region Sales and for the other director it is Western Region Sales.

If a user has multiple assignments, the application builds a hierarchy for each assignment, using each assignment’s organization as the top organization. The user can then see the people and assignments in any of their assignments’ subordinate organizations.

Security Profiles By Position and Position Hierarchies

After establishing limits on record access using organization hierarchies, you can further restrict access by means of position hierarchies.

Suppose, for example, within the Sales Department, you want to give the Sales Research Director access to her subordinates’ records only. There are two ways of doing this: either with or without user-based security.

You can start by building the following Sales Positions Hierarchy:

Sales Positions Hierarchy

Without User-Based Security

Create the Sales Research Director security profile. This profile references the Sales Positions hierarchy and names the Sales Research Director as the top position for access to employee records.

Security Profile:	SALES RESEARCH DIRECTOR
Organization Hierarchy:	Sales Organization
Top Organization:	Sales Department
Position Hierarchy:	Sales Positions
Top Position:	Sales Research Director
Include Top Position:	Yes

When you give the Sales Research Director a responsibility including this security profile, she can access the records of her subordinates. But, she cannot access records of the:

• VP or Associate VP of Sales
  
• Regional Sales Director
  
• Regional Sales Director’s subordinates

As with organization hierarchies, you can specify that profiles do not include access to the top position.

With User-Based Security

If you are using user-based security, you can choose to use the position linked to the user’s assignment as the top position. The top position is then determined dynamically when the user logs on or when the Security List Maintenance process is run. To illustrate the advantage of using user-based security in this way, take the above example. Instead of having to create a separate security profile for each position hierarchy, for example, a Sales Research Director profile and an Associate Sales Research Director profile, you could create one security profile which would identify the top position based on the user’s assignment. In the example, the security process would identify that the top position for the Sales Research Director is different from the top position for the Associate Sales Research Director and build the position hierarchy accordingly.

If a user has multiple assignments, the application builds a hierarchy for each assignment, using each assignment’s position as the top position. The user can then see the people and assignments in any of their assignments’ subordinate position hierarchies.

Defining a Security Profile

You can define security profiles in the Security Profile window (to give access to a single business group) or the Global Security Profile window (to allow users to access records from more than one business group).

See also: Security Profiles

Note: Using the Global Security Profile window does not give Oracle HRMS users access to records from multiple business groups within the same responsibility; users must still switch responsibilities to see records from different business groups. However, HRMS users can see a restricted set of information in records from more than one business group within a single responsibility if the HR:Cross Business Profile profile option is set to Yes. In addition, you can use people management templates to query and update worker information across business groups using a single responsibility.

If you want to associate a reporting user with the new security profile, the ORACLE database administrator must create a new reporting user ORACLE ID. The system administrator must register the new ORACLE IDs as restricted privilege users with the Application Object Library.

See: Setting up Reporting Users

To define a security profile

1. Enter a name for the security profile.
   
2. If you are using the Security Profile window, select a business group. Users will have access only to records within this business group. This does not need to be the business group associated with your responsibility.
   If you are using the Global Security Profile window, users will have security access to records from all business groups, subject to other restrictions you set up.
   
3. If you want reporting users to be able to use this security profile, select the Reporting User name for the ID set up by the database administrator (this option is not available when setting up Global Security).
   Applying Restrictions by Person Type
4. You can choose to apply the security restrictions you set up to employees, applicants, contingent workers, contacts, candidates or any combination of these. 
   Note: You can only restrict access to candidates if you have iRecruitment installed. If you do not have iRecruitment, the application uses the default setting of All for the View Candidates box.
   For example:
   
   • If you want the security restrictions to apply to employees, select Restricted from the View Employees box.
     
   • To ignore the security restrictions for employees and allow access to all employees, select All from the View Employees box.
     
   • To prevent access to any employee records, even if the other security restrictions allow access, select None from the View Employees box.
   You can set the View Applicants, View Contingent Workers, and, if you have iRecruitment, View Candidates, options independently, giving different security access to employees, applicants, contingent workers, and candidates using the same security profile.
   For contacts, or other people of person type Other, you can choose one of two options:
   
   • All: Access is unrestricted, so that all people of type Other are visible to the security profile
     
   • Restricted: The profile restricts access to contacts to those people who are related to employees, applicants, or contingent workers who are visible within the security profile. If you can see the record of an employee, applicant, or contingent worker, you can also see the records of people of type Other specified as related to them (using the Contact Relationship field). All people of type Other who are unrelated to any employee, applicant, or contingent worker are also visible to the security profile.
   Allowing Access to Granted User Records (SSHR only)
5. Select the Allow Granted Users option to allow a self-service user with this security profile to access the records of other self-service users, provided that the other users grant them access using the self-service application.
   Note: This setting applies to the self-service application only and has no effect on users of Oracle HRMS.
   Restricting Access by Individual Assignment
6. Select the Restrict on Individual Assignments option to build security hierarchies based on a person’s individual assignments. Oracle HRMS builds the security hierarchy and assesses each individual assignment. The hierarchies generated by the security process will then only contain the particular assignments to which the manager has access. If you do not select this option, a manager who can see one assignment for a person can see all other assignments.
   For more information on restricting by individual assignment and securing your forms, see: Assignment-Level Security.
   Restricting Access by Organization
7. In the Organization Security tabbed region:
   
   • To restrict by organization list, select the Secure organizations by organization hierarchy and/or organization list option in the Security Type poplist. Select the organizations in the Organization Name field, and choose the Include option button. 
     
   • To restrict by organization hierarchy, select the Secure organizations by organization hierarchy and/or organization list option. Select an organization hierarchy, and a top organization. Select the Include Top Organization option if you want to allow access to this organization. 
     If you are using user-based security, you can choose to use the organization linked to a person’s assignment as the top organization by selecting the corresponding option. The security process identifies the organization linked to the user’s assignment when the user logs on (or when the Security List Maintenance process is run). 
     If required, you can add organizations not in the hierarchy to the list, by selecting the organizations in the Organization Name field and choosing the Include option button. You can also remove specific organizations from the selected hierarchy by selecting an organization in the Organization Name field and choosing the Exclude option button.
   Note: The Secure organizations by single operating unit and Secure organizations by operating unit and inventory organizations options are for use by non-HRMS users, and have no effect on the HRMS application.
   
8. By default, the Exclude Business Groups check box is unchecked, giving users access to the business groups themselves, and therefore to employees or applicants who have the business group(s) as their organization. Check the box to prevent access to the business group(s) and the employees or applicants attached to them (for example, to prevent users from seeing new starters and other employees who have been assigned to the business group by default).
   Restricting Access by Position (not Global Security)
9. In the Position Security tabbed region, deselect the View All Positions option. Select a position hierarchy, and a top position. Check the Include Top Position check box if you want to allow access to this position.
   If you are using user-based security, you can choose to use the position linked to a person’s assignment as the top position by selecting the corresponding option. In this case, the security process identifies the position linked to the user when the user logs on (or when the Security List Maintenance process is run).
   Restricting Access by Payroll (not Global Security)
10. In the Payroll Security tabbed region:
    
    • To give access to all payrolls, check the View All Payrolls check box.
      
    • To give access to many payrolls, uncheck the View All Payrolls check box, and uncheck the Include check box. Select the payrolls you want to exclude.
      
    • To give access to a small number of payrolls, uncheck the View All Payrolls check box, and check the Include check box. Select the payrolls to include.
    Restricting Access by Supervisor
11. In the Supervisor Security tabbed region, you can further specify how to create your supervisor hierarchy. You can either create a hierarchy based on a person’s supervisor assignment or based on a person’s supervisor. 
    For more information, see: Security Profiles for Supervisor Security.
    Select either the person-based or assignment-based option and enter the number of levels of access you want to allow the supervisor to see in the Maximum Hierarchy Levels box (or leave the field blank to allow access to all levels).
    Note: When you set up security based on supervisor hierarchies, you can choose to generate the list of employees visible to a user at the start of the session (user-based security). For supervisors with a large number of subordinates (for example, at higher management levels) leaving the Maximum Hierarchy Levels box blank may result in a delay in generating the list. You can improve performance by limiting the number of hierarchy levels a supervisor can access or by using the Static List functionality.
    For more information, see: Static Lists.
    Alternatively, for the highest levels of management, consider setting up security using organization hierarchies.
    
12. If you are using person-based supervisor security, you can choose whether to display multiple assignments in the supervisor hierarchy. By default, the Primary Assignments Only option is not selected, which gives users access to people who report to them in any assignment. If you only want to give users access to people who report to them in their primary assignment, select this option.
    Miscellaneous Restrictions
13. The list of people whose records are accessible using a security profile can change with the user name of the person who logs in (if you are using user-based security). If you want the application to evaluate permissions based on a specific person (and not vary depending on the user name of the person who logs in) enter a name in the Named User field. For example, to set up supervisor-based security for reporting users who do not have any association with employees, enter the name of a person at the required supervisory level.
    To prevent users from seeing their own records, check the Exclude User check box (if you have entered a name in the Named User box, users will be prevented from seeing the records of the named user rather than their own records).
    Note: This functionality is not supported in Self-Service Human Resources (SSHR).
    Restricting Access by Custom Security
14. In the Custom Security tabbed region, select the custom restriction option. The options are as follows:
    
    • No custom security
      
    • Restrict the people visible to this profile
      The Security List Maintenance process is the basis for this type of custom security. The security data is held in a static list.
      
    • Restrict the people visible to each user using this profile
      Oracle HRMS assesses the custom security when the user signs on. In addition, the custom security code can include references to user specific variables, for example, fnd_profile.value() and fnd_global.employee_id.
15. Enter a valid SQL WHERE clause fragment to select a group of records. For example, to add a restriction that assignments must be based in either London or Paris, add the following SQL fragment:
    ASSIGNMENT.location_id in (select LOC.location_id from hr_locations_all LOC where LOC.location_code in ('London','Paris')) Alternatively, you could create custom code to use user-specific variables. The following example illustrates the use of user-specific variables:
    In this example, the custom code creates a rule whereby a user can display employees or contingent workers whose last name begins with the same letter as their own. The security profile is called “Same first letter of last name”. 
    substr(person.last_name,1,1) = (select substr(i.last_name,1,1) from per_all_people_f i where i.person_id = fnd_global.employee_id and trunc(sysdate) between i.effective_start_date and i.effective_end_date) Note: In addition, the View Employees or View Contingent Workers option is set to Restricted, and the “Restrict the people visible to each using this profile” option is set on the Custom Security tab.
    If the clause is valid, it is automatically incorporated in an SQL select statement that the system generates to restrict access to records, based on the restrictions you have set up in the other tabbed regions. The list of employees, contingent workers, and applicants specified by these other restrictions is therefore further restricted by the custom restriction.
    The clause fits into the system-generated statement in the following way (this statement is not visible on screen):
    select 1 from per_all_assignments_f ASSIGNMENT, per_all_people_f PERSON, per_person_type_usages_f PERSON_TYPE where ASSIGNMENT.assignment_id=:asg_id and:effective_date betweeen ASSIGNMENT.effective_start_date and ASSIGNMENT.effective_end_date and PERSON.person_id=ASSIGNMENT.person_id and :effective_date between PERSON.effective_start_date and PERSON.effective_end_date and PERSON.person_id=PERSON_TYPE.person.id and :effective_date between PERSON_TYPE.effective_start_date and PERSON_TYPE.effective_end_date and {your custom where clause fragment goes here} Important: Custom restrictions directly restrict employees, contingent workers, and applicants only; you cannot create custom restrictions on people with a system person type of Other. However, if you add custom restrictions on employees, contingent workers, or applicants, related people with a system person type of Other are restricted according to the setting of the “View Contacts” option.
    
16. Choose the Verify button to check that the clause you have entered is valid. If it is invalid, an error message appears explaining the reasons.
    Using Static Lists
17. Static lists enable you to assess security periodically and store the data. You add users to the static list and their security permissions are evaluated when the Security List Maintenance process is run. Oracle HRMS stores the permissions for quick retrieval when the user logs on and freezes the permissions until you run the Security List Maintenance process again. 
    To specify which users to include in a static list, enter the user ID in the field.
    
18. To include a specific user or group of users in the next Security List Maintenance run, select the Process in Next Run option for those users. 
    
19. Save your work.
    

When you have modified or created new security profiles, it may be necessary to run security processes to activate your changes.

See: Security Processes

See: Running the Security List Maintenance Process

Assigning Security Profiles

Use the Assign Security Profile window to link user names, and security profiles to responsibilities. Only use this window if you are using Security Groups Enabled security (formerly called Cross Business Group Responsibility security).

Important: When using Security Groups Enabled security even if you have linked a user to a responsibility using the User window, you must still link your user to responsibility and security profile using the HRMS Assign Security Profile window. If you do not use the Assign Security Profile window, HRMS uses the default view-all security profile for the Business Group and the user will see all records for the Business Group.

The Assign Security Profile window is an essential part of setting up and maintaining HRMS security for Security Groups Enabled security. You must use this window to update your security profile assignment. Any changes entered for the security profile assignment are also shown on the User window. However, if you end date a user’s responsibility using the User window, this is not shown on the Assign Security Profile window.

When you navigate to the Assign Security Profile window, the Find Security Profile Assignments window displays automatically. Select New to create a new assignment. For information about querying existing security profile assignments, see Using the Find Security Profile Assignment window.

To assign a new security profile

1. Enter the user name you want to link to a responsibility.
   
2. Enter the application and responsibility you want to link to the user. 
   
3. To assign a local security profile, select a business group to assign to the user’s responsibility. The local security profile for the business group is automatically entered when you click in the Security Profile field.
   
4. To assign a global security profile, first select the security profile to assign to the user’s responsibility, thenselect a business group. 
   Note: If you enter a value in the Business Group field first, the list of security profiles is filtered and does not display security profiles for any other business groups.
   You can link more than one security profile to a responsibility as long as the user is different. 
   
5. Enter the time period of security profile assignment.
   You must enter a start date. Optionally, enter an end date if you want the security profile assignment to end on a particular date. 
   
6. Save the security profile assignment.
   

To end a security profile assignment

You cannot delete security profile assignments. If a user no longer needs an assignment you must enter an end date.

1. Query the security profile assignment you want to end.
   
2. Enter an end date. The user cannot use this responsibility, Business Group and security profile from this date.
   

Using the Find Security Profile Assignment window

This window enables you to search for security profile assignments that have already been set up. You only use security profile assignments if you are setting up Security Groups Enabled security.

If you want to set up a new security profile assignment select the New button. For more information on setting up new security profile assignments, see Assigning Security Profiles.

Note: When you navigate to the Assign Security Profiles window, the Find Security Profile Assignment window automatically displays.

To query a security profile assignment

1. Enter a full or partial query on one, a selection or several of the following:
   
   • User name
     
   • Application
     
   • Responsibility
     
   • Business group
     
   • Security profile
   Note: If you enter a value in either the Business Group or the Security Profile field, any value entered in the other field is blanked out if it is not valid to select both. For example, you cannot select both business group A and a security profile which is specific to business group B.
   
2. Check the Retrieve Only Active Assignments check box if you want to query security profile assignments that are active as of today’s date. Uncheck the Retrieve Only Active Assignments check box if you want to query security profile assignments which are no longer active or assignments which will be available in the future.
   
3. Choose the Find button.
   The security profile assignments found by the query are displayed in the Assign Security Profile window. 
   

Running the Security List Maintenance Process

You run the Security List Maintenance (SLM) process to update the lists of organizations, positions, employees and applicants that security profiles can access. You should run this process regularly, for example nightly, to take account of changes made during the day.

See Security Processes

You run the Security List Maintenance process from the Submit Requests window.

To run the Security List Maintenance Process

1. In the Name field, select Security List Maintenance.
   
2. In the Parameters window, enter the date for which you want to run the report in the Effective Date field. If you do not enter a date the process runs for the current system date.
   
3. In the Generate lists for field, select the range of security profiles for which you want to run the process. You can choose to update:
   
   • All Global Security Profiles (all profiles created using the Global Security Profile window)
     
   • All Security Profiles
     
   • All Security Profiles in One Named Business Group
     
   • One Named Security Profile
     
   • One Specified User in One Named Security Profile
4. If you have selected All Security Profiles in One Named Business Group, select a business group.
   
5. If you have selected One Named Security Profile, select a security profile.
   
6. If you have selected One Specified User in One Named Security Group, select a security profile and the user name.
   
7. In the Process field, select the type of people to be processed. You can choose from the following values:
   
   • Current people only
     
   • Terminated people only
     
   • Current and Terminated people
     Note: If you have selected One Named Security Profile, the only available option is Current and Terminated people.
8. In the Static User Processing field, choose whether to run the process for all static users or only those users selected for inclusion in the next processing run (selected on the Static Users tab of the Security Profile window).
   Note: You can use this parameter only if you have chosen a processing option other than One Specified User in One Named Security Group.
   
9. In the Use Temporary Space field, select Yes to store data in the PER_PERSON_LIST_STAGE table when the SLM process runs. PER_PERSON_LIST_STAGE is a temporary staging table and the data is stored temporarily. If the data is stored in the temporary table, then this action avoids locking the records of active users in the PER_PERSON_LIST actual table when the SLM process runs. During the final stages of the SLM process, the application copies data from the PER_PERSON_LIST_STAGE table to the PER_PERSON_LIST table.
   Note: You can use this parameter only if you have chosen ‘One Named Security Profile’ as the processing option 
   
10. Choose OK.
    
11. Complete the batch process details and choose the Submit button.
    

Running the Change Candidate Access for Security Profiles Process

This process enables you to change candidate access settings for your security profiles. This process is intended for use only if you use iRecruitment.

Warning: The process changes the candidate access settings for all security profiles except the default View All security profiles that the system creates automatically when you create a business group. You should be aware of this before you run the process.

System Implications

With the introduction of Candidate Security, the default setting for the View Candidates box in the Define Security Profiles window is All. However, if you use both Oracle HRMS and iRecruitment, you will generally have some security profiles that should allow access to candidates and some that should not allow access. In this case, you can run the Change Candidate Access for Security Profiles process to override the security settings.

For example, if the majority of your security profiles should allow access to candidates, you can run the process with the View Candidates parameter set to All. This would reset the candidate access for all security profiles. Then, you could manually change the View Candidates setting to None for those security profiles that should not allow candidate access using the Define Security Profiles window.

See: Defining Security Profiles

You run the Change Candidate Access for Security Profiles process from the Submit Requests window.

Prerequisites

• This process is not delivered in any request sets or groups. To use the process, you need to add the process to a request group and, if applicable, a request set.

To run the Change Candidate Access for Security Profiles process

1. In the Name field, select Change Candidate Access for Security Profiles.
   
2. In the View Candidates field of the Parameters window, select one of the following values:
   
   • All
     Select this value to update your security profiles to include candidates.
     
   • None
     Select this value to update your existing security profiles to exclude candidates.
3. Choose OK and submit the process.
   

Running the Purge Security Profiles Process

Run the Purge Security Profiles process to remove security profiles that are not in use from database. Run this program to first identify security profiles that are not used and then purge all the unused security profiles or any specific security profile that is not required.

For information on security profiles, see: Security Profiles

You run this process from the Submit Request window.

Prerequisites

• This process is not delivered in any request sets or groups. To use the process, you must add the process to a request group and, if applicable, a request set.

To run the Purge Security Profiles process

1. In the Name field, select Purge Security Profiles.
   
2. Select Yes in the List Unused Security Profiles field if you want to view a list of security profiles that are not in use. Click OK and then Submit. Navigate to the Find Requests window, search for your request ID, and then view log of the request. Review the list of unused security profiles. Based on your analysis, you can perform step 3 or 4.
   Note: You can directly purge all unused security profiles or a specific security profile, if required, without performing step 2. You must set the mandatory parameter List Unused Security Profiles to No to perform step 3 or 4.
   
3. Select Yes in the Purge all Unused Security Profiles field to remove data of security profiles that are not in use.
   
4. Enter the name of the specific security profile that you want to purge in the Security Profile Name field. This security profile must be one of the security profiles list generated in step 2.
   
5. Click OK and submit the process.