Guidelines for Securing Positions

This topic describes guidelines to consider when deciding how to secure access to position records, by securing by area of responsibility and position hierarchy. It also describes how to preview access provided by the security profile for a user before saving.

Securing by Area of Responsibility

When you secure position records by area of responsibility, the set of records that the user can access is calculated dynamically. The calculation is based on the user's assigned areas of responsibility. For example, a user may be the HR representative for a specific department. You create the position security profile based on these values. That is, you set Responsibility Type to Human resources representative and Scope to Department. In this case, any user who has that responsibility for a department can access position records defined for that department. If the user later becomes responsible for positions in a different department, then you update only that user's area of responsibility. The position security profile remains valid without update. You can also create a single data role to include the position security profile and assign it to multiple representatives. The option to secure access by position list remains available, which enables you to refine further the list of positions that users can access. For performance reasons, you're recommended to secure access to position records by area of responsibility whenever possible.

When you select the Area of Responsibility section in any position security profile, the Position Hierarchy and Workforce Structures sections become unavailable. These criteria are incompatible with securing by area of responsibility.

Securing by Position Hierarchy

Oracle HCM Cloud supports both position trees and the HCM Position Hierarchy. Depending on the values of the enterprise Position Hierarchy Configuration options, you can secure access to position records using either type of hierarchy.

Note: Any future enhancements related to position hierarchies will support only the HCM Position Hierarchy. Therefore, you should consider using the HCM Position Hierarchy rather than position trees.

You set the Position Hierarchy Configuration options on the Manage Enterprise HCM Information page. They determine whether the Position Tree field appears in the Position Hierarchy section of the Create Position Security profile page.

  • If you select only Use HCM Position Hierarchy, then the Position Tree field is hidden.

  • If you select only Use Position Trees, then the Position Tree field appears.

  • If you select both options, then the Hierarchy Type field appears, where you can select either the HCM Position Hierarchy or the position tree.

When you edit an existing position security profile, the enterprise options have no effect. If the existing position security profile is based on the position tree, then the Position Tree field appears. Otherwise, the Position Tree field is hidden.

Previewing the Security Profile

Creating a position security profile is a two-step process. Once you have defined your security criteria, you click Next to open the Create Position Security Profile: Preview page. Here, you can test the access provided by the security profile before you save it. On the Position Access Preview tab, you can select a user and click Preview. This action returns the number of position records that this security profile allows the user to access. You also see the name and type of the user's areas of responsibility, if any. You can then identify individual position records to which the security profile provides access by searching for them. The search is based on criteria such as position name, business unit, and incumbent. The search is performed within the set of position records that was returned by the Preview action.

You can review the automatically generated SQL predicate for your security criteria on the SQL Predicate for Position Access tab.

Note: The results from the Position Access Preview are based on the current position security profile only. Users may have many roles that provide access to other position records.