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, 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
Internal Organizations 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.
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.
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.
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.
Note: 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.
No comments:
Post a Comment