Oracle® Fusion Applications Coexistence for HCM Implementation Guide 11g Release 5 (11.1.5) Part Number E20378-03

Contents

Contact Us

Previous

Next

17 Define Data Security for Human Capital Management

This chapter contains the following:

HCM Security Profiles: Explained

HCM Securing and Secured Objects: Explained

HCM Data Roles: Explained

Creating HCM Data Roles and Security Profiles: Points to Consider

Creating Organization Security Profiles: Examples

Securing Organizations: Points to Consider

Creating Person Security Profiles: Examples

Securing Person Records by Manager Hierarchy: Points to Consider

Specifying the Manager Type: Explained

Securing Person Records by Workforce Structures: Points to Consider

Securing Person Records Using Custom Criteria: Examples

Creating Position Security Profiles: Examples

Creating Document Type Security Profiles: Examples

Assigning Security Profiles to Abstract Roles: Explained

Assigning Security Profiles to Abstract Roles: Worked Example

Creating an HCM Data Role: Worked Example

HCM Data Roles Configuration Diagnostic Test

HCM Security Profile Configuration Diagnostic Test

HCM Securing Objects Metadata Diagnostic Test

FAQs for Define Data Security for Human Capital Management for Coexistence

HCM Security Profiles: Explained

A security profile defines the criteria that identify instances of a human capital management (HCM) object. For example, a person security profile defines the criteria that identify one or more person records, and a position security profile defines the criteria that identify one or more positions. When you include a security profile in an HCM data role and provision the data role to a user, that user can access the data instances identified in the security profile. The type of access available to the user (for example whether the user can edit or simply view the data) depends on the job role identified in the HCM data role.

HCM Object Types

You can create security profiles for the following HCM object types:

• Person

  • Managed person

  • Public person

• Organization

• Position

• Legislative data group (LDG)

• Country

• Document type

• Payroll

• Payroll flow

• Workforce business process

All security profile definitions for these HCM objects are eventually visible in the Oracle Fusion Middleware Authorization Policy Manager (APM). The name of the security profile's data instance set in the Oracle Fusion Middleware APM is derived from the name of the security profile and the relevant object type. For example, if the security profile name is Manager Hierarchy, then the data instance set for the object PER_ALL_PEOPLE_F is HCM:PER:PER_ALL_PEOPLE_F:Manager Hierarchy.

You must use the Oracle Fusion Human Capital Management interfaces, which are designed for ease of use and access, to create and maintain security profiles; do not use the Oracle Fusion Middleware APM to maintain security profiles for these HCM objects.

Security Criteria in HCM Security Profiles

In any HCM security profile, you specify the criteria that identify data instances of the relevant type. For example, in an organization security profile, you can identify organizations by organization hierarchy, by organization classification, or by listing organizations to include in or exclude from the security profile. All of the criteria in an HCM security profile apply when the data instance set is defined; for example, if you identify organizations by both organization hierarchy and organization classification, then both sets of criteria apply, and only those organizations that satisfy all criteria belong to the data instance set.

Predefined HCM Security Profiles

The following HCM security profiles are predefined:

You can include the predefined security profiles in any HCM data role, but you cannot edit them. Note also that the View all option is disabled in any security profile that you create; this restriction exists because predefined security profiles exist for this requirement.

Creating Security Profiles

You can create security profiles either individually or as part of the process of creating an HCM data role. If you have standard requirements, it may be more efficient to create the security profiles individually and include them in appropriate HCM data roles.

Reusability and Inheritance of Security Profiles

Regardless of how you create them, all security profiles are reusable; they do not belong to particular HCM data roles, and you can include them in any HCM data role for which they define an appropriate data instance set.

You can include security profiles in other security profiles. For example, you can include an organization security profile:

• In a person security profile, to secure person records by department, business unit, or legal employer

• In a position security profile, to secure positions by department or business unit

Therefore, one security profile can inherit the data instance set defined by another.

HCM Securing and Secured Objects: Explained

Human capital management (HCM) objects to which access is secured by HCM data roles are identified as either securing objects or secured objects.

HCM Securing Objects

The person, organization, position, country, legislative data group (LDG), document type, payroll, payroll flow, and workforce business process objects are referred to as HCM securing objects. An HCM securing object secures access to both its own data and data in child or related objects. For example, access to a specified organization can also allow access to associated model profiles. Instances of HCM securing objects that users can access are identified in security profiles. The type of security profile that you use to identify instances of an HCM securing object is fixed; for example, you identify person records in a person security profile and position records in a position security profile.

Whether a particular user can access all of the secured data in practice is controlled by data security policies: for example, a compensation manager may be able to enter salary details for a specified set of person records, while a benefits manager may be able only to view salary details in the same set of person records.

HCM Secured Objects

An HCM secured object is a business object to which access is controlled by its relationship with a securing object. For example, salary details are secured objects that are secured by the person securing object.

Securing objects can also be secured objects. For example, access to person records can be controlled by person data, such as person type or name range, or by other securing objects, such as organization or position, or both.

HCM Data Roles: Explained

HCM data roles, like all Oracle Fusion Applications data roles, define data security policies: they enable users to perform a set of tasks, using identified menus, menu items, and pages in application user interfaces, on a specified set of data within those user interfaces. Because data roles are specific to the enterprise, no predefined HCM data roles exist.

How HCM Data Roles Differ from Other Data Roles

HCM data roles differ from other data roles in the following ways:

• You create and maintain HCM data roles outside Oracle Identity Management (OIM) and the Oracle Fusion Middleware Authorization Policy Manager (APM), and they are not based on data role templates.

  Although HCM data roles are visible in the Oracle Fusion Middleware APM, they must not be maintained there.

• A single HCM data role can enable access to data of multiple types.

  You identify the data that users can access in HCM security profiles. You can create security profiles for the person, organization, position, country, legislative data group (LDG), document type, payroll, payroll flow, and workforce business process objects.

Selecting the Job Role

Each HCM data role is associated with a single job role, which you select from the list of enterprise roles. The HCM securing objects that the selected role needs to access are identified automatically, and the appropriate types of security profile are displayed. For example, if you select the job role human resource analyst, users with that job role need to access managed person, public person, organization, position, LDG, and document type data; therefore, security profiles for those object types must be included in the HCM data role. The security profile types that appear in the HCM data role vary according to the data requirements of the selected job role.

If you select a job role that requires no access to HCM data secured by security profiles, you cannot create an HCM data role.

Creating or Selecting the Security Profiles

You can either create new security profiles or use existing security profiles. For each object type, you can include only one security profile in an HCM data role.

Users with Multiple HCM Data Roles

When users have multiple HCM data roles, the data security policies arising from each role remain separate. For example, being able to promote or terminate workers in the purchasing department in one HCM data role and view contact details of all workers in the sales department in another HCM data role does not enable a user to promote or terminate workers in the sales department.

Components of the HCM Data Role

The following figure summarizes how the components of the HCM data role contribute to Oracle Fusion Data Security for the data role. Oracle Fusion Data Security comprises the data security policies for data roles that are generated automatically when data roles are created.

The job role that you select in the HCM data role inherits multiple duty roles. Each duty role has one or more function privileges and related data privileges, from which the relevant HCM objects are identified. The specific instances of the objects required by this HCM data role are identified in security profiles and stored in a data instance set. Data security policy data is created automatically in Oracle Fusion Data Security when you create the data role.

For example, the human resource specialist job role inherits the employee hire and worker promotion duty roles, among many others. The inherited duty roles provide both function privileges, such as Hire Employee, Rehire Employee, and Promote Workers, and data privileges to HCM objects, such as person and assignment. The specific instances of those objects required by this HCM data role, such as people with assignments in a specified legal employer and department, are identified in security profiles.

Creating HCM Data Roles and Security Profiles: Points to Consider

Planning your use of HCM data roles and security profiles before you start creating them will enable you to minimize maintenance and ease the introduction of HCM data roles and security profiles in your enterprise.

Identifying Standard Requirements

In any enterprise, standard requirements for data access are likely to exist. For example, multiple HCM data roles may need access to all person records in a specific legal employer. If you create a person security profile that includes all person records in that legal employer, then you can include the security profile in as many HCM data roles as necessary. This approach simplifies the management of HCM data roles and security profiles, and may also prevent duplicate security profiles being created unnecessarily.

Naming HCM Data Roles and Security Profiles

You are recommended to define and use a naming scheme for HCM data roles and security profiles.

Ideally, a security profile name identifies clearly the scope of the resulting data instance set so that, when creating or updating an HCM data role, users can confidently select an appropriate HCM security profile. For example, the person security profile name All Employees Sales Department conveys clearly that the security profile identifies all employees in the sales department.

The name of an HCM data role usefully includes both the name of the inherited job role and the data role scope. For example, the HCM data role Human Resource Analyst Finance Division identifies both the job role and the organization within which the role operates. HCM data role names must be less than 55 characters.

Planning Data Access for Each HCM Data Role

An HCM data role can include only one security profile of each type. For example, you can include one organization security profile, one managed person security profile, and one public person security profile. Therefore, you must plan the data-access requirements of any HCM data role to ensure that each security profile identifies all required data instances. For example, if a user needs to select legal employers, business units, and departments, then organizations of all three types must be identified by the organization security profile that you include in the HCM data role.

Providing Access to All Instances of an Object

To provide access to all instances of an HCM object, use the appropriate predefined security profile. For example, to provide access to all person records in the enterprise, use the predefined security profile View All People.

Creating Organization Security Profiles: Examples

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.

HR IT Administrator Who Maintains Organizations

The HR IT administrator maintains the definitions of all types of organizations for the enterprise. You want the HR IT administrator's access to reflect any changes to the hierarchy without needing to update the security profile. Therefore, you:

• Secure by organization hierarchy.

• Select a generic organization hierarchy, so that the security profile data instance set includes organizations of all classifications.

• Identify by name the top organization in the hierarchy that will be included in the data instance set of organizations. The HR IT administrator's needs are fixed; therefore, the top organization is unlikely to vary with the user's assignment.

If you secured by organization classification, you would need to update the security profile if organizations of different classifications were added to the user's responsibilities. Similarly, if you listed organizations to include in or exclude from the instance set, you would need to maintain the list as the enterprise's organization hierarchy evolved.

Human Resource Specialist Who Manages Person and Assignment Records in a Legal Employer

The human resource (HR) specialist needs access to lists of legal employers, business units, departments, reporting establishments, and disability organizations while creating and updating person records and assignments. To identify the organizations that the user can see in such lists, you:

• Secure by organization hierarchy.

• Select a generic organization hierarchy, because the HR specialist needs access to more than one type of organization.

• Allow the top organization in the hierarchy to be the department from the user's assignment. This selection allows you to provision the HCM data role in which this organization security profile is included to multiple HR specialists who may be employed in different parts of the enterprise.

If the generic hierarchy contains organizations of types that the HR specialist does not need to access, you can additionally identify the classifications to be included. If additional organizations of the included classifications are later added to the hierarchy, you do not need to update the security profile. You would need to update the security profile only if the user became responsible for organizations of other classifications in the same HCM data role.

The HR specialist also needs access to person records, and one of the ways in which those records can be secured is by organization. If the set of organizations is the same, you can reuse this organization security profile to secure the person records in a person security profile.

Securing Organizations: Points to Consider

Some users maintain organization definitions for part or all of the enterprise, and some users need to access lists of organizations while performing other tasks, such as creating assignments. While the access requirements in each case are very different (and depend on the job role inherited by the user's HCM data role) for both types of user you identify relevant organizations in an organization security profile.

Organizations With Multiple Classifications

Organizations may have more than one classification. For example, a department may also be classified as a legal employer. An organization is included in 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 is also a legal employer appears in the organization security profile data instance set because it is a department. However, users of this organization security profile will not be able to access the organization as a legal employer.

Selecting the Top Organization in an Organization Hierarchy

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

Users With Multiple Assignments

When you select the department from the user's assignment as the top organization in an organization hierarchy, multiple top organizations may exist when the user has multiple assignments. In this case, all organizations from the relevant subhierarchies of the selected 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 organization B and one in organization D, which belong to the same organization hierarchy. The top organizations are organizations B and D, and the user's data instance set of organizations therefore includes organizations B, E, D, F, and G.

Creating Person Security Profiles: Examples

A person security profile identifies person and assignment records by at least one of the following types of criteria: person type, manager hierarchy, workforce structure, global name range, and custom criteria.

These examples show typical requirements for person security profiles.

Human Resource Specialists for a Legal Employer

Human resource (HR) specialists for the ABC legal employer need access to the person and assignment records of anyone who has a work relationship with the legal employer. You create a person security profile named All ABC Workers. In the security profile, you:

• Secure by person type and select the system person types employee, contingent worker, nonworker, and pending worker.

• Set the access level to restricted for the selected person types.

• Secure by legal employer, and select an existing organization security profile that identifies legal employer ABC and any subordinate organizations. The person security profile All ABC Workers inherits the organization security profile's data instance set.

The data instance set from the person security profile All ABC Workers comprises all employees, contingent workers, nonworkers, and pending workers in legal employer ABC.

If you do not:

• Secure by person type, then the data instance set includes all person types, including those without work relationships, such as emergency contacts

• Set the access level for these person types to restricted, then other criteria in the security profile are ignored; therefore, the data instance set includes all workers in the enterprise rather than in legal employer ABC

As you set the access level separately for each person type, you could set it to restricted for some person types and unrestricted for others. The other criteria in the security profile would apply only to the person types with restricted access.

You can include the security profile All ABC Workers in an HCM data role and provision the data role to any HR specialist in legal employer ABC.

Enterprise Line Managers

You want to enable line managers in your enterprise to access the person and assignment records of people who report to them directly from at least one assignment. You also want line managers to have access to the person and assignment records of people who report to the assignments that they manage directly. Your management hierarchy comprises eight management levels, and you want to limit the number of levels of the hierarchy that each manager can access.

You create a person security profile named Line Manager Three Levels. In the security profile, you:

• Secure by manager hierarchy, and set the Person or Assignment Level option to Assignment.

• Set Maximum Levels in Hierarchy to 3, to ensure that the data instance set for any line manager comprises no more than 3 levels of the manager hierarchy.

• Set Manager Type to Line Manager.

You can include this security profile in an HCM data role and provision that data role to any line manager in the enterprise.

Payroll Administrators for a Subset of Employees

Payroll administrators in Ireland need to be able to access the person and assignment records of employees. In Ireland, your enterprise has a large number of employees and several payroll administrators. You decide that some payroll administrators will manage the records of people whose names are in the range A through M and some will manage those in the range N through Z. Therefore, you create two person security profiles, Ireland Employees A to M and Ireland Employees N to Z.

• In both security profiles, you

  • Secure by person type, select the employee system person type, and set the access level to restricted.

  • Secure by legal employer and select an existing organization security profile that identifies legal employers in Ireland.

• In the person security profile Ireland Employees A to M, you secure by global name range and set the range to A through M.

• In the person security profile Ireland Employees N to Z, you secure by global name range and set the range to N through Z.

You include each person security profile in a separate HCM data role, which you provision to appropriate payroll administrators. If necessary, you can provision both HCM data roles to a single payroll administrator. In this case, the payroll administrator would have access to employees in Ireland whose names are in the range A through Z.

Securing Person Records by Manager Hierarchy: Points to Consider

When you identify a set of person records by manager hierarchy, the person records that occur in the data instance set for the signed-on manager depend on how you specify the manager hierarchy in the person security profile.

You can select one of:

• Person-level manager hierarchy

• Assignment-level manager hierarchy

In both cases, the selection controls access to person records. Having access to a person's record enables the manager to access all of the person's assignments: you cannot enable the manager to access particular assignments.

Consider the following example manager hierarchy.

Harry is a line manager with two assignments. In his primary assignment, he manages Sven's primary assignment. In his assignment 2, Harry manages Jane's primary assignment. Monica is a line manager with one assignment. She manages Jane's assignment 2 and Amir's primary assignment. In her primary assignment, Jane manages Franco's primary assignment. In her assignment 2, Jane manages Kyle's primary assignment.

Person-Level Manager Hierarchy

In a person-level manager hierarchy, the data instance set includes the person records of any person who is in a reporting line, directly or indirectly, to any of the signed-on manager's own assignments.

In a person-level manager hierarchy, Harry's data instance set includes the person records for Sven, Jane, Franco, and Kyle.

In a person-level manager hierarchy, Monica's data instance set includes the person records for Jane, Franco, Kyle, and Amir.

In a person-level manager hierarchy, Jane's data instance set includes the person records for Franco and Kyle.

When you include the person security profile in an HCM data role and assign the data role to a manager, the person-level hierarchy ensures that the signed-on manager can access the person record and all assignment records of every person in his or her manager hierarchy (subject to any other criteria in the security profile).

Assignment-Level Manager Hierarchy

In an assignment-level manager hierarchy, managers see the person records of:

• People who report to them directly from one or more assignments

• People who report to the assignments that they manage

In an assignment-level manager hierarchy, Harry's data instance set includes Sven, Jane, and Franco. It does not include Kyle, because Kyle reports to an assignment that Monica manages.

In an assignment-level manager hierarchy, Monica's data instance set includes Jane, Kyle, and Amir. It does not include Franco, because Franco reports to an assignment that Harry manages.

In an assignment-level manager hierarchy, Jane's data instance set includes Franco and Kyle.

An assignment-level manager hierarchy is not the same as assignment-level security, which would secure access to individual assignments: you cannot secure access to individual assignments.

Specifying the Manager Type: Explained

When you secure person records by manager hierarchy, the data instance set comprises person records from manager hierarchies of the specified types.

If you set Manager Type to:

• All, the security profile includes all types of manager hierarchies

• Line Manager, the security profile includes only the line manager hierarchy

• Selected, the security profile includes only the specified type of manager hierarchy

Typically, you select Line Manager to identify the data instance set for line managers, Project Manager to identify the data instance set for project managers, and so on. If you select All, then users with the line manager job role (for example) will have line-manager access to person records in all of their manager hierarchies, which may not be what is required.

Manager Job Roles

Manager job roles other than line manager are not predefined. Creating job roles for managers such as project managers and resource managers is a security-customization task. Once those roles exist, you can assign security profiles to them (either directly or by creating a separate HCM data role) to enable users with those roles to access their manager hierarchies in the Manager Resources Dashboard and elsewhere.

Securing Person Records by Workforce Structures: Points to Consider

In a person security profile, you can identify a set of person records by one or more of the department, business unit, legal employer, position, payroll, and legislative data group (LDG) workforce structures. For example, the data instance set from a person security profile could include all workers who occupy a particular position at a specified legal employer.

Identifying the Work Structures

You identify each of the work structures using a security profile of the relevant type.

To identify:

• Departments, business units, and legal employers, you use organization security profiles

• Positions, you use a position security profile

• LDGs, you use an LDG security profile

• Payrolls, you use a payroll security profile

These security profiles are reusable: you can include them in any person security profile where they can identify the relevant data instance set of person records. The person security profile inherits the data instance set of any security profile that you include.

Using Assignment-Level Attributes

Although the department, business unit, payroll, and position values are assignment attributes, you cannot secure access to individual assignments. Therefore, if one of a person's assignments satisfies the criteria in a person security profile, then all of the person's assignments belong to the person security profile's data instance set.

Securing Person Records by LDG

When you secure person records by LDG, a person's record and all assignments belong to the person security profile's data instance set if the LDG is associated with the payroll statutory unit of the person's legal employer.

Securing Person Records by Payroll

When you secure person records by payroll, a person's record and all assignments belong to the person security profile's data instance set if at least one of the person's assignments includes the payroll.

Securing Person Records by Legal Employer

If you secure person records by legal employer, then the person records and all assignments of workers with at least one work relationship of any type with the specified legal employer belong to the person security profile's data instance set. For such workers, assignments belonging to work relationships with other legal employers also belong to the data instance set.

Other criteria in the person security profile may limit the effects of securing by legal employer. For example, if you also secure person records by person type, select the employee system person type, and specify restricted access, then only persons who have employee work relationships with the specified legal employer belong to the security profile's data instance set. All other person records are excluded.

Securing Person Records Using Custom Criteria: Examples

You can secure person records by person type, manager hierarchy, workforce structures, and global name range. You can also specify custom criteria, in the form of SQL statements, in addition to or in place of the standard criteria. The custom criteria can include any statement where the predicate restricts by PERSON_ID or ASSIGNMENT_ID: the custom predicate must include either &TABLE_ALIAS.PERSON_ID or &TABLE_ALIAS.ASSIGNMENT_ID as a restricting column in the custom criteria.

The following scenario illustrates how to use custom criteria in a person security profile.

Identifying Persons Born Before a Specified Date

The person security profile data instance set must include employees in a single legal employer who were born before 01 January, 1990. You secure person records by:

• Person type, where you select the employee system person type and set the access level to restricted

• Legal employer, where you select an organization security profile that identifies the relevant legal employer and its subordinate organizations

You also secure by custom criteria, and enter the following statement:

&TABLE_ALIAS.PERSON_ID IN (SELECT PERSON_ID FROM PER_PERSONS
WHERE DATE_OF_BIRTH < TO_DATE('01-JAN-1990', 'DD-MON-YYYY'))

Creating Position Security Profiles: Examples

Some users need to maintain position definitions for part or all of the enterprise. Other users need to access lists of positions when creating user assignments, for example. The users' access requirements vary, but in both cases you identify the positions that users can access in a position security profile.

These scenarios show typical uses of position security profiles.

Human Resource Specialist Managing Position Definitions

The human resource (HR) specialist creates and maintains position definitions for the enterprise, with a few exceptions. To identify the set of positions that HR specialists can manage, you:

• Secure by position hierarchy, select the enterprise position hierarchy tree, and identify the top position for which the HR specialist is responsible. You include the top position in the hierarchy.

• Secure by position list, and identify by name the few positions for which the HR specialist is not responsible. You exclude these positions from the position security profile data instance set.

You can include this security profile in the relevant HCM data role and provision it to any HR specialist in the enterprise who has responsibility for these position definitions.

Line Manager Hiring Workers

Line managers in your business unit can hire employees or add contingent workers when the positions of those new workers are below the managers' own positions in the position hierarchy. To identify the set of positions that line managers can allocate to new workers, you secure by position hierarchy, select the relevant position tree, and use the position from the user's assignment as the top position. You do not include the top position in the hierarchy.

You can include this position security profile in the relevant HCM data role and provision it to any line manager in your business unit.

Securing Person Records by Position

Some senior managers in your enterprise can access the person records of workers who occupy positions below them in the position hierarchy; therefore, you secure access to those person records by position in the person security profile. To identify the relevant positions, you create a position security profile in which you secure by position hierarchy, identify the senior manager position as the top position, and do not include it in the hierarchy. This selection ensures that senior managers do not have access to the person records of other senior managers.

Creating Document Type Security Profiles: Examples

Some users need to manage document types for the enterprise. Others need to be able to manage the documents associated with the person records to which they have access. For example, workers need to be able to manage their own documents. The users' access requirements vary, but in both cases 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.

Workers Managing Their Own Documents

Workers can manage their own documents from their portraits. If you create an HCM data role for a worker's job role, for example, you can include the predefined document type security profile View All Document Types, which includes all locally defined document types. Alternatively, you can create a document type security profile that includes specified document types only. In the document type security profile, you list document types either to include in the profile or to exclude from it. For example, if you have defined the document type Medical Record that you want only human resource (HR) specialists to manage, you could create a document type security profile for workers that excludes medical records. Workers would continue to have access to all other document types in the enterprise.

HR Specialists Managing Document Types

HR specialists who are responsible for managing the enterprise document types need to access all document types. You can provide this access by including the predefined document type security profile View All Document Types in the HCM data role that you provision to HR specialists who have this responsibility. This security profile also ensures that HR specialists can view and update all document information in the person records that they manage.

Assigning Security Profiles to Abstract Roles: Explained

Abstract roles define a worker's role in the enterprise independently of the job that the worker is hired to do.

These abstract roles are predefined in Oracle Fusion Human Capital Management:

• Line manager

• Employee

• Contingent worker

Enabling Data Access for Abstract Roles

Typically, you create role mappings during implementation to provision abstract roles automatically to eligible workers. Although users with these roles may be able to sign in to Oracle Fusion Applications and navigate to tasks of interest, they have no automatic access to data. For example, employees can navigate to the Person Gallery but cannot view portraits or see lists of person names in product interfaces, and line managers can navigate to the Manager Resources Dashboard but can see no data for their organizations. To enable users with abstract roles to access relevant HCM data, you must assign security profiles to those abstract roles.

Predefined Security Profiles to Assign to Abstract Roles

To enable users with abstract roles to access relevant data, you assign the following predefined security profiles directly to the employee, contingent worker, and line manager abstract roles.

After implementation, you may want to change aspects of this data access. For example, you may want to create your own security profiles and assign those directly to abstract roles; however, you must remember that such changes apply to all users who have the abstract role.

HCM Data Roles

Users who have abstract roles are likely to gain additional data access by means of HCM data roles that you define for their job roles. For example, you may create an HCM data role for human resource specialists to enable them to access the person records of all workers in a legal employer. Such data access is in addition to any data access provided by abstract roles.

Assigning Security Profiles to Abstract Roles: Worked Example

This example shows how to assign predefined security profiles to the employee, contingent worker, and line manager abstract roles.

Searching for the Employee Abstract Role

1. On the All Tasks tab of the Overview page of the Setup and Maintenance work area, search for the task Manage Data Role and Security Profiles.
2. In the Search Results region, click Go to Task.
3. On the Manage Data Roles and Security Profiles page, enter the abstract-role name Employee in the Role field. Click Search.
4. In the Search Results region, highlight the entry for the predefined Employee role and click Assign.

Assigning Security Profiles to the Employee Abstract Role

1. On the Assign Data Role: Security Criteria page, select the security-profile values shown in the following table. These are the security profiles that are typically assigned to the employee role. You may see a subset of these security profiles, depending on the combination of product offerings that you are implementing.

   Field	Value
   Organization Security Profile	View All Organizations
   Position Security Profile	View All Positions
   Country Security Profile	View All Countries
   LDG Security Profile	View All Legislative Data Groups
   Person Security Profile (Person section)	View Own Record
   Person Security Profile (Public Person section)	View All Workers
   Document Type Security Profile	View All Document Types

   
   
2. Click Review.
3. On the Assign Data Role: Review page, click Submit.
4. On the Manage Data Roles and Security Profiles page, search again for the predefined Employee role.
5. In the Search Results region, confirm that a green check mark appears in the Security Profiles column for the Employee role. The check mark confirms that security profiles are assigned to the role.

   Repeat the steps in Searching for the Employee Abstract Role and Assigning Security Profiles to the Employee Abstract Role for the predefined Contingent Worker role.

Searching for the Line Manager Abstract Role

1. On the Manage Data Roles and Security Profiles page, enter the abstract-role name Line Manager in the Role field. Click Search.
2. In the Search Results region, highlight the entry for the predefined Line Manager role and click Assign.

Assigning Security Profiles to the Line Manager Abstract Role

1. On the Assign Data Role: Security Criteria page, select the security-profile values shown in the following table. These are the security profiles that are typically assigned to the line manager role. You may see a subset of these security profiles, depending on the combination of product offerings that you are implementing.

   Field	Value
   Organization Security Profile	View All Organizations
   Position Security Profile	View All Positions
   LDG Security Profile	View All Legislative Data Groups
   Person Security Profile (Person section)	View Manager Hierarchy
   Person Security Profile (Public Person section)	View All Workers
   Document Type Security Profile	View All Document Types
   Payroll Flow	View All Flows
   Workforce Business Process	View All Workforce Business Processes

   
   
2. Click Review.
3. On the Assign Data Role: Review page, click Submit
4. On the Manage Data Roles and Security Profiles page, search again for the predefined Line Manager role.
5. In the search results, confirm that a green check mark appears in the Security Profiles column for the Line Manager role. The check mark confirms that security profiles are assigned to the role.

Creating an HCM Data Role: Worked Example

This example shows how to create an HCM data role.

The legal employer ABC Industrial comprises sales, development, and manufacturing departments. This example shows how to create an HCM data role for a human resource (HR) specialist in the sales department of ABC Industrial that will secure access to person and assignment records, organizations, positions, countries, legislative data groups (LDGs), document types, payrolls, and payroll flows.

The following table summarizes key decisions for this scenario.

Summary of the Tasks

Create the HCM data role by:

1. Naming the HCM data role and selecting the associated job role

2. Specifying the security criteria for each HCM object type

3. Creating new security profiles

4. Reviewing and submitting the new HCM data role

Naming the HCM Data Role and Selecting the Job Role

1. In the Search Results region of the Manage HCM Data Roles page, click Create.
2. On the Create Data Role: Select Role page, complete the fields as shown in this table.

   Field	Value
   Data Role	HR Specialist ABC Industrial - Sales Department
   Job Role	Human Resource Specialist

   
   
3. Click Next.

Specifying Security Criteria for Each HCM Object Type

1. In the Organization region of the Create Data Role: Security Criteria page, complete the fields as shown in the table.

   Field	Value
   Organization Security Profile	Create New
   Name	ABC Industrial - All Organizations
   Secure by organization hierarchy	Yes

   
   
2. In the Position region, complete the fields as shown in the table

   Field	Value
   Position Security Profile	Create New
   Name	ABC Industrial Positions - Top Position Vice President of Sales
   Secure by position hierarchy	Yes

   
   
3. In the Countries region, select the predefined country security profile View All Countries.
4. In the Legislative Data Group region, select the existing LDG security profile ABC Industrial LDGs.
5. In the Person region, complete the fields as shown in the table.

   Field	Value
   Person Security Profile	Create New
   Name	ABC Industrial Sales Department - All Workers and Worker Contacts
   Include related contacts	Yes
   Secure by person type	Yes
   Secure by department	Yes

   
   
6. In the Public Person region, select the predefined person security profile View All People.
7. In the Document Type region, select the predefined document type security profile View All Document Types.
8. In the Payroll region, select the existing payroll security profile ABC Industrial Payrolls.
9. In the Payroll Flow region, select the existing payroll flow security profile ABC Industrial Payroll Flows.
10. Click Next.

Creating the Organization Security Profile

1. In the Organization Hierarchy region of the Assign Security Profiles to Role: Organization Security Profile page, ensure that the Secure by organization hierarchy option is selected.
2. Complete the fields in the Organization Hierarchy region as shown in the table.

   Field	Value
   Tree Structure	Generic organization hierarchy
   Organization Tree	ABC Industrial Organization Tree
   Top Organization Selection	Use the assignment department
   Include top organization	Yes

   
   
3. Click Next.

Creating the Position Security Profile

1. In the Position Hierarchy region of the Assign Security Profiles to Role: Position Security Profile page, ensure that the Secure by position hierarchy option is selected.
2. Complete the fields in the Position Hierarchy region as shown in the table.

   Field	Value
   Position Tree	ABC Industrial Positions
   Top Position Selection	Specify top position
   Position	Vice President of Sales
   Include top position	Yes

   
   
3. Navigate to the Assign Security Profile to Role: Person Security Profile page.

Creating the Person Security Profile

1. In the Basic Details region of the Assign Security Profiles to Role: Person Security Profile page, ensure that the option Include related contacts is selected.
2. In the Person Types region, ensure that the Secure by person type option is selected, and complete the fields as shown in the table.

   Type	System Person Type	Access
   System	Employee	Restricted
   System	Contingent worker	Restricted
   System	Nonworker	Restricted
   System	Pending worker	Restricted

   
   
3. In the Workforce Structures region, ensure that the option Secure by department is selected, and select the existing organization security profile ABC Industrial - Sales Department.
4. Click Review.

Review and Submit the HCM Data Role

1. On the Create Data Role: Review page, review the new HCM data role.
2. Click Submit.
3. On the Manage HCM Data Roles page, search for the new HCM data role. In the search results, confirm that the role status is Requested. Once the role status is Request Complete, the role can be provisioned to users.

HCM Data Roles Configuration Diagnostic Test

The HCM Data Roles Configuration diagnostic test verifies that the Manage HCM Data Roles task flow is configured successfully for a specified user.

You run the HCM Data Roles Configuration diagnostic test from the Help - Troubleshooting - Run Diagnostic Tests menu.

Diagnostic Test Parameters

The test is performed for the specified user. The user does not need to be signed-in while the test is running; however, the user must have signed in at least once, because the test uses details from the user's current or latest session.

HCM Security Profile Configuration Diagnostic Test

The HCM Security Profile Configuration diagnostic test verifies that the Manage Security Profiles task flows are configured successfully for a specified user.

You run the HCM Security Profile Configuration diagnostic test from the Help - Troubleshooting - Run Diagnostic Tests menu.

Diagnostic Test Parameters

The test is performed for the specified user. The user does not need to be signed-in while the test is running; however, the user must have signed in at least once, because the test uses details from the user's current or latest session.

HCM Securing Objects Metadata Diagnostic Test

The HCM Securing Objects Metadata diagnostic test validates securing-object metadata for the HCM securing objects.

You run the HCM Securing Objects Metadata diagnostic test from the Help - Troubleshooting - Run Diagnostic Tests menu.

Diagnostic Test Parameters

Enter the name of an HCM securing object from the following table.

If you do not enter the name of a securing object, the test is performed for all securing objects.

FAQs for Define Data Security for Human Capital Management for Coexistence

Can users access the contact records of the people they can access?

Having access to a person's record does not automatically provide access to the records of that person's emergency contacts, dependents, or beneficiaries. However, you can include the person records of a person's contacts in the person security profile's data instance set by selecting the Include related contacts option.

What happens if a person has multiple assignments or person types?

A user who has access to a person record also has access to all of the person's assignments; only one of the assignments has to satisfy any assignment-related criteria in the person security profile. For example, if a user can access the records of contingent workers in a particular legal employer and department, then the user can access all assignments belonging to those contingent workers, even if some are employee or nonworker assignments with different legal employers.

What happens if a person has no assignments?

Some person records, such as those of emergency contacts, have no assignments. The person records of people who have no assignments do not need to satisfy any assignment-related criteria, such as department and position, in the person security profile. Person records without assignments belong to the person security profile data instance set, provided that they satisfy any person-related criteria (person type, global name range, or custom criteria) in the person security profile. Such records are an exception to the general rule that all of the criteria in a security profile must be satisfied.

What's the difference between a generic organization hierarchy and a department hierarchy?

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 those organizations that are classified as departments.

What happens if I select an organization security profile for a generic organization hierarchy?

If you secure by department, for example, only those organizations in the generic organization hierarchy that are classified as departments have an effect in the security profile. Other types of organizations in the generic organization hierarchy, such as business units and legal employers, are disregarded.

If you secure by more than one workforce structure, you can select the same organization security profile for each type of work structure. In each case, only organizations of the relevant organization classification have an effect.

What happens if I use the department or position from the user's assignment as the top department or position?

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

If the user has multiple assignments in the selected organization or position hierarchy, then multiple top organizations or positions may exist. In this case, all organizations or positions from the relevant subhierarchies belong to the security profile's data instance set.

When do I need a country security profile?

Country security profiles identify one or more countries to appear in lists of countries. For example, a user who is creating a legislative data group must associate it with a country; the list of countries that the user sees is determined by the country security profile included in the user's HCM data role. The predefined country security profile View All Countries meets most needs and can be included in any HCM data role. However, you can limit the country list available to a particular HCM data role by creating a country security profile for that data role. The countries that you can include in the country security profile are those defined in the table FND_TERRITORIES.

When do I need a legislative data group security profile?

You need a legislative data group (LDG) security profile to identify one or more LDGs to which you want to secure access. If the responsibility for managing all LDGs in your enterprise belongs to a particular HCM data role, include the predefined LDG security profile View All Legislative Data Groups in the data role. If responsibility for particular LDGs belongs to various HCM data roles, you can create an appropriate LDG security profile for each data role. For example, if European and American LDGs are the responsibility of different HCM data roles, you need one LDG security profile for European LDGs and one for American LDGs.

You can use an LDG security profile to secure access to person records. In this case, if the LDG is associated with the payroll statutory unit of a person's legal employer, then that person's record belongs to the person security profile data instance set.

When do I need a workforce business process security profile?

Workforce business process security profiles identify the workforce business processes that a user can start from the Start Process menu in the Workforce Processes work area. The predefined security profile View All Workforce Business Processes includes all registered workforce business processes. To enable users to start all workforce business processes, you include the predefined security profile in relevant HCM data roles; you do not need to create a workforce business process security profile to provide this access.

To enable users to start some but not all workforce business processes, you must:

• Create a workforce business process security profile that identifies the workforce business processes that the user can start.

• Include the new workforce business process security profile in relevant HCM data roles.

What happens if I edit a security profile that's enabled?

If the security profile is included in an HCM data role, then the data instance set for the security profile is updated automatically when you save your changes. For example, if you remove a position from a position security profile, the position is removed from the data instance set of the relevant position security profile. At the next attempt to access the data identified in the security profile, the user finds the updated data instance set.

What happens if I disable a security profile?

When the security profile is included in an HCM data role, users continue to access the tasks associated with their job roles or abstract roles because security profiles have no effect on function security privileges. However, no data is returned from the disabled security profile. For example, an administrator authorized to update organization definitions would continue to access organization-related tasks, but would not be able to access the organizations identified in a disabled organization security profile.

You cannot disable a security profile that is included in another security profile.

How do I provision HCM data roles to users?

You can map any role, including HCM data roles, to one or more assignment attributes. For example, you can map a role to a particular legal employer, department, and job. This mapping indicates that the role is relevant to users whose assignment attributes match those specified.

If the role mapping for a role has the Autoprovision option selected, then the role is provisioned automatically to any user with at least one assignment that matches all specified attributes.

If the role mapping for a role has the Requestable option selected, then any human resource specialist or line manager with at least one assignment that matches all specified attributes can provision the role manually to other users.

If the role mapping for a role has the Self-requestable option selected, then any user with at least one assignment that matches all specified attributes can request the role.

What happens if I edit an HCM data role?

You can edit or replace the existing security profiles in an HCM data role. When you save your changes, the relevant data instance sets are updated. Users with this HCM data role find the revised data instance sets when they next sign in.

You cannot change the HCM data role name nor select a different job role. If you need to make such changes, you must create a new HCM data role and disable this HCM data role, if appropriate.

How can I diagnose any issues with HCM data roles and security profiles?

After creating HCM data roles and security profiles, you can run diagnostic tests from the Help - Troubleshooting - Run Diagnostic Tests menu to diagnose any issues.

The following diagnostic tests are available:

Previous

Next

Copyright ©  2011-2012, Oracle and/or its affiliates. All rights reserved. Legal Notices

Contents

Contact Us