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:
Security Rules

1-45

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
1-46 Oracle Human Resources Management Systems Configuring,
Reporting, and System Administration Guide
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 assignmentlevel 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, page 1-31.
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
Security Rules

1-47

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:
1-48 Oracle Human Resources Management Systems Configuring,
Reporting, and System Administration Guide
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
Security Rules

1-49

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 userbased 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, page 1-31 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.
1-50 Oracle Human Resources Management Systems Configuring,
Reporting, and System Administration Guide
See: Setting up Reporting Users, page 1-26
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
Security Rules

1-51

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, page 1-36.
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
1-52 Oracle Human Resources Management Systems Configuring,
Reporting, and System Administration Guide
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, page 1-24, 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
Security Rules

1-53

supervisor assignment or based on a person's supervisor.