18Organization and Other Security Profiles

This chapter contains the following:

How You Secure Organizations

A valid organization security profile can secure access to all organizations in the enterprise or any subset of those organizations. This topic explains how to set the criteria in an organization security profile to identify a specific set of organizations.

You can use any combination of the following three sections of the organization security profile to identify a set of organizations:

  • Organization Hierarchy

  • Organization Classification

  • Organization List

In the Organization List section, you can select some organizations to include and some to exclude. All criteria that you specify in all sections apply.

The following table identifies the set of organizations that results from each combination of criteria in the organization security profile.

Hierarchy Classification List (Exclude) List (Include) Set of Organizations

Yes

No

No

No

All organizations in the specified hierarchy

No

Yes

No

No

All organizations of the selected classifications in the enterprise

No

No

Yes

No

All organizations in the enterprise, minus those listed

No

No

No

Yes

The listed organizations

Yes

Yes

No

No

Organizations of the selected classifications that belong to the specified hierarchy

Yes

No

Yes

No

All organizations in the specified hierarchy, minus those listed

Yes

No

No

Yes

All organizations in the specified hierarchy, plus those listed

No

Yes

Yes

No

All organizations of the selected classifications, minus those listed

No

Yes

No

Yes

All organizations of the selected classifications, plus those listed

Yes

Yes

Yes

No

All organizations of the selected classifications in the specified hierarchy, minus those listed

Yes

Yes

No

Yes

All organizations of the selected classifications in the specified hierarchy, plus those listed

Yes

Yes

Yes

Yes

All organizations of the selected classifications in the specified hierarchy, plus and minus those listed

The following rules apply to use of the Organization List section of the organization security profile:

  • When you add an organization to the Organization List section and select Include, that organization is added to the security profile instance set. Typically, you do this when an organization isn't identified by the other criteria in the security profile. For example, you could include the Legal Employer classification and add a department to the Organization List section. No error would occur if you included a legal employer in the Organization List section, even though that organization was already included.

  • When you add an organization to the Organization List section and select Exclude, that organization is excluded from the security profile instance set. Typically, you do this when an organization is identified by the other criteria in the security profile. For example, you could include a department hierarchy and add one of those departments to the Organization List section to exclude it. No error would occur if you included a legal employer in the Organization List section, even though legal employers were already excluded.

Some users maintain organization definitions. Others access lists of organizations while performing tasks such as creating assignments. The access requirements for these users differ. However, for both types of users you identify relevant organizations in an organization security profile. This topic discusses the effects of options that you select when creating an organization security profile. To create an organization security profile, use the Manage Organization Security Profile task.

Organizations with Multiple Classifications

Organizations may have more than one classification. For example, a department may also have the legal employer classification. An organization belongs to an organization security profile data instance set if it satisfies any one of the security profile's classification criteria. For example, if you secure by department hierarchy only, a department that's also a legal employer is included because it's a department.

Securing by Organization Classification

To secure access to all organizations of a single classification, select the classification in the Secure by Organization section. For example, to secure access to all legal employers in the enterprise, set the Classification Name in the Secure by Classification section to Legal Employer. You can exclude selected legal employers from this access by listing them in the Organizations section and selecting Exclude in the Include or Exclude Organizations column.

Selecting the Top Organization in an Organization Hierarchy

If you select a named organization as the top organization in an organization hierarchy, then you must ensure that the organization remains valid. No automatic validation of the organization occurs, because changes to the organization hierarchy occur independently of the organization security profile.

Users With Multiple Assignments

You can select the department from the user's assignment as the top organization in an organization hierarchy. Multiple top organizations may exist if the user has multiple assignments. In this case, all departments from the relevant subhierarchies of the organization hierarchy belong to the organization security profile data instance set.

The following figure illustrates the effects of this option when the user has multiple assignments.

The user has two assignments, one in department B and one in department D, which belong to the same organization hierarchy. The top organizations are therefore departments B and D, and the user's data instance set of organizations therefore includes departments B, E, D, F, and G.

This figure shows a hierarchy of departments. Department
A at the top inherits departments B, C, and D. Department B inherits
department E. Department D inherits departments F and G. As the user
has assignments in departments B and D, he or she can access all departments
in this hierarchy except departments A and C.

An organization security profile identifies organizations by at least one of organization hierarchy, organization classification, and organization list.

These examples show some typical requirements for organization security profiles. Use the Manage Organization Security Profile task to create organization security profiles.

HR IT Administrator Who Maintains Organizations

The HR IT administrator maintains all types of organizations for the enterprise. The user's access must reflect any changes to the organization hierarchy without requiring updates to the security profile. Therefore, you:

  • Secure by organization hierarchy.

  • Select a generic organization hierarchy. The hierarchy includes all types of organizations.

  • Identify by name the top organization in the hierarchy. The top organization is unlikely to vary with the user's own assignments.

If you secure by organization classification or list organizations by name, then you must maintain the security profile as the organization hierarchy evolves.

Human Resource Specialist Who Manages Employment Records in a Legal Employer

The human resources (HR) specialist accesses lists of various organizations, such as legal employers and business units, while managing employment information. To identify the organizations that the user can see in such lists, you:

  • Secure by organization hierarchy.

  • Select a generic organization hierarchy, because the user accesses more than one type of organization.

  • Use the department from the user's assignment as the top organization in the hierarchy. Using this value means that you can assign an HCM data role that includes this organization security profile to multiple HR specialists.

This topic describes some aspects to consider when deciding how to secure access to position records. It also describes how to preview the access provided by the security profile for a specified user before you save it.

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.

These scenarios show typical uses of position security profiles. To create a position security profile, use the Manage Position Security Profile task.

Human Resource Specialist Who Manages Position Definitions

Human resource (HR) specialists manage position definitions for specific business units. Each HR specialist has a defined area of responsibility, where the Responsibility Type is set to Human resources representative and the business unit is selected. In the position security profile, you:

  • Secure by area of responsibility.

  • Set Responsibility Type to Human resources representative and Responsibility Scope to Business unit.

You can include this security profile in a data role and provision the role to any HR specialist who manages positions in a business unit.

Tip: You can also secure by position list. For example, you could list positions to add to the set identified using area of responsibility.

Line Manager Who Hires Workers

Line managers in your legal employer can hire workers whose positions are below the managers' own positions in the position hierarchy. The managers' positions must be associated with active assignments. Your enterprise is using the HCM Position Hierarchy. To identify these positions, you:

  • Secure by position hierarchy.

  • Set Top Position to Use positions from all active user assignments.

  • Deselect Include Top Position.

You can include this position security profile in a data role and provision the role to any line manager in your legal employer.

Some users manage document types for the enterprise. Others manage documents associated with the person records that they access. For example, workers manage their own documents. For all access requirements, you identify the document types that users can access in a document type security profile.

These scenarios show typical uses of document type security profiles. To create a document type security profile, use the Manage Document Type Security Profile task.

Note: Document type security profiles secure access to administrator-defined document types only. They don't secure access to standard predefined document types, such as visas, work permits, and driver's licenses. Access to person records provides access to the standard predefined document types.

Workers Managing Their Own Documents

Workers can manage their own documents by editing their personal information. Implementors typically assign the predefined security profile View All Document Types directly to the employee and contingent worker roles. Workers can therefore access their own documents.

Alternatively, you can create a document type security profile that includes specified document types only. In the security profile, you list document types to either include or exclude. For example, you could create a document type security profile for workers that excludes disciplinary or medical documents. Workers would access all other document types.

Human Resource Specialists Managing Document Types

Human resource (HR) specialists who manage the enterprise document types must access all document types. You can provide this access by including the predefined security profile View All Document Types in the HCM data role for HR specialists. Using this security profile, HR specialists can also manage documents of administrator-defined types in the person records that they manage.

You use a legislative data group (LDG) security profile to identify one or more LDGs to which you want to secure access. Use the Manage Legislative Data Group Security Profile task in the Setup and Maintenance work area.

View All Legislative Data Groups Security Profile

The predefined LDG security profile View All Legislative Data Groups provides access to all enterprise LDGs. Use this security profile wherever appropriate. For example, if users with a particular HCM data role manage all enterprise LDGs, then include View All Legislative Data Groups in that data role.

Creating LDG Security Profiles

If responsibility for particular LDGs belongs to various HCM data roles, then you create an appropriate LDG security profile for each data role. For example, you may need one LDG security profile for European LDGs and one for American LDGs.

By default, users who can access the Transaction Console can manage all transactions on the console. However, you may want to limit access so that users can manage only Talent or Compensation transactions, for example. This topic explains how to secure transactions on the Transaction Console so that users can access only specified categories of transactions.

How to Secure Access to Transactions on the Transaction Console

To secure access to transactions on the Transaction Console, you have to do a few things:

  1. Create transaction security profiles.

  2. Create data roles and assign transaction security profiles to them.

  3. Assign the data roles to users.

  4. Enable transaction security.

You don't have to create the transaction security profiles separately. If you prefer, you can create them when you create the data roles. This topic explains how to create them separately, but the key steps are the same in both cases.

Creating Transaction Security Profiles

Use the Manage Transaction Security Profiles task to select the transaction types that users can manage. You can find this task in the Workforce Structures or Setup and Maintenance work area.

On the Create Transaction Security Profile page, you:

  1. Click the Create New icon.

  2. Set Family to the appropriate product family.

  3. Select a category. This value identifies a category of transactions that users can manage. Categories that you don't select are excluded.

  4. Optionally, select a subcategory.

    • The subcategory identifies transactions in the subcategory only. All other subcategories in the category are excluded, unless you select them separately.

    • If you select Exclude Subcategory, then users can manage transactions in the category, apart from those in the excluded subcategory.

You can repeat these steps to add other categories of transactions to the security profile. When you're finished, save your changes.

Creating Data Roles

To create a data role, you can use:

  • The Manage Data Roles and Security Profiles task in the Workforce Structures work area

  • The Assign Security Profiles to Role task in the Setup and Maintenance work area

The data role must:

  • Inherit either the predefined Human Capital Management Application Administrator job role or a custom role with the required privileges.

    • The predefined Human Capital Management Application Administrator job role inherits the Review HCM Approval Transactions as Administrator duty role. You can assign this duty role to custom roles.

    • The Review HCM Approval Transactions as Business User duty role isn't inherited by any predefined role. It enables a restricted set of actions on the Transaction Console. You can assign this duty role to custom roles, such as Human Resource Specialist.

  • Have an assigned transaction security profile. This security profile identifies the types of transactions that users can manage on the Transaction Console. You can:

    • Select a transaction security profile that you created using the Manage Transaction Security Profiles task.

    • Create a security profile in the data roles task flow.

    • Use one of the predefined security profiles, View All Transactions and View All HCM Transactions.

Create as many data roles as you need, and assign them to users. On the Transaction Console, those users can manage transactions:

  • That were created by people identified by the data role's person security profile

  • That belong to the categories in the data role's transaction security profile

Note that both conditions apply. You must also enable transaction security. Otherwise, users who can access the Transaction Console can manage all transactions, even if their data roles limit them to specified types of transactions.

Enabling Transaction Security

Transaction security is disabled by default. To enable transaction security, you use the Manage Enterprise HCM Information task. You can find this task:

  • In the Workforce Structures work area

  • In the Setup and Maintenance work area in the Workforce Structures functional area for your offering

Follow these steps:

  1. On the Edit Enterprise page, select Edit > Update.

  2. Complete the fields in the Update Enterprise dialog box and click OK.

  3. Scroll to the Transaction Console Information section. In the Transaction Console Information section, select Enable Transaction Security.

  4. Click Submit.

You have to enable transaction security once only. While it's enabled, access to transactions on the Transaction Console is secured, and users can manage only the transactions that their data roles allow.

You can used these different methods to provide access to payrolls for members of the Payroll department. Organize your payroll definitions into appropriate payroll security profiles using the Manage Payroll Security Profiles task. Then you use the Assign Security Profiles to Role task to select the security profiles included in an HCM data role that you provision to a user.

Payroll Period Type

It is common to use the payroll security profile to organize payroll definitions by payroll period type. You simply create one security profile for each payroll type, such as monthly payrolls, another for semimonthly payrolls, and so on.

Regional Assignments

You can use payroll security profiles to group payrolls by the regions of the employees' work areas. For example, you can create one for Canadian facilities and another for European facilities.

Individual Contributors

If your payroll managers can access only the payroll definitions that they manage, use create payroll security profiles to include only those payrolls.

You can use different methods to organize payroll flows into appropriate security profiles. Use the Assign Security Profiles to Role task in the Setup and Maintenance work area to grant workers access to those profiles by data role.

Scenario

Here's a few examples of payroll security profiles and data roles.

Example Data Role Security Profile

Payroll Processing and QuickPay Flows

Payroll Administrator

Payroll Cycle flow and the QuickPay flow

End-of -Year Reporting

Payroll Administrator

End-of -Year flow and the Archive End-of-Year Payroll Results flow

Hiring and Terminations

HR Administrator or HR Specialist

New Hire flow and the Termination flow

Your HCM data role security determines which flows you can submit or view. This topic explains how the HCM data roles and flow security work together. Use the Manage Payroll Flow Security Profile task in the Setup and Maintenance work area to define security for payroll flow patterns.

Payroll Flow Security and HCM Data Roles

HCM data roles secure the access to flows through data privileges and to the tasks on a checklist through functional privileges.

  • When you submit a flow pattern, it generates a checklist of the included tasks.

  • You become the owner of the flow and its tasks. If a flow pattern designates tasks to different owners, you remain the flow owner.

  • Either you or the owner of a task can reassign the task to someone else. For example, to cover situations where the task is overdue and the task owner is on leave.

This figure illustrates how the payroll manager and payroll administrator can submit a process or report and can view the results of the monthly payroll flow.

Payroll manager and administrator can perform same
task

  • The payroll manager or the payroll administrator can submit the flow and perform its tasks or have the tasks reassigned to them.

  • The payroll manager and the payroll administrator can perform the same tasks because both of them have the same functional privileges.

  • They can both submit and view the payroll flow data.

This figure illustrates how only the payroll manager can calculate the payroll. The payroll manager can't reassign this task to a payroll administrator, because the administrator doesn't have the necessary functional privileges to submit the monthly payroll flow action.

Payroll manager can perform the task. Payroll administrator
doesn't have the functional privilege to perform the task.

Troubleshooting

If you encounter problems submitting or completing a task in a flow, these are the actions you can take.

Problem Solution

Can't submit or view a flow

Confirm that the data role assigned to you includes a security profile for the payroll flow pattern.

Can't perform a task, such as a process or report

Confirm that your data role is based on a job or abstract role that includes functional privileges to perform that task.

FAQs for Organization and Other Security Profiles

A generic organization hierarchy is a single hierarchy that includes organizations of all classifications, such as division, legal entity, department, and tax reporting unit.

A department hierarchy includes only organizations with the department classification.

If you secure by department, for example, the data instance set includes only organizations with the department classification from the generic organization hierarchy. The data instance set excludes other types of organizations.

Therefore, you can select the same organization security profile for multiple work structure types.

The user's access to the organization or position hierarchy depends on the user's assignments. Therefore, the data instance set from a single security profile may be different for each user.

For a user with multiple assignments in the hierarchy, multiple top organizations or positions may exist. All organizations or positions from the relevant subhierarchies appear in the data instance set.

Country security profiles identify one or more countries to appear in lists of countries. The predefined country security profile View All Countries meets most needs. However, you can limit the country list available to an HCM data role by creating a country security profile for that role. The countries that you can include are those defined in the table FND_TERRITORIES.

By default, users with these predefined job and abstract roles see all countries in lists of countries:

  • Benefits Administrator

  • Benefits Manager

  • Benefits Specialist

  • Compensation Manager

  • Contingent Worker

  • Employee

  • Human Capital Management Integration Specialist

  • Human Resource Specialist

  • Line Manager

If you include any of these roles in a data role, then users with the data role see all countries. The country security profile that you include in the data role has no effect.

By default, users can view job requisitions when they're members of the job requisition hiring team. They can also see the job requisitions that their subordinates can see. You can define job requisition security profiles and include them in HCM data roles to enable users to view other job requisitions. For example, you can secure access to job requisitions by location or recruiting type.

Users can access future-dated persons, organizations, or positions that satisfy the security profile criteria. If you leave this option deselected, then users can't access future-dated objects. For example, users couldn't see an organization with a future start date, even though it satisfied all other criteria in the security profile.

Date-effective records in objects aren't affected by this option.