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
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, and applicant 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
Suggestion: 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.
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 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.
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.
Additional Information: 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.
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.
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.
Attention: 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 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.
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.
If you use user-based security profiles and have huge volume of security data to process, then set the HR: Evaluate User Access using Minimal Cache profile option to improve the system performance while evaluating security profiles. Set the profile option for responsibilities that are attached to the user-based profiles only. For more information, see: User Profiles.
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.
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
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.
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