Browser version script Skip Headers

Oracle® Fusion Applications Coexistence for HCM Implementation Guide
11g Release 1 (11.1.3)
Part Number E20378-01
Go to contents  page
Contents
Go to Previous  page
Previous
Go to previous page
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

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

Creating an HCM Data Role: Worked Example

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:

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:


Security Profile Name

HCM Security Profile Type

Description

View All People

Person

Identifies all person records in the enterprise

View Own Record

Person

Identifies the signed-on user's own person record and the person records of that user's contacts

View Manager Hierarchy

Person

Identifies the signed-on manager's hierarchy

View All Workers

Person

Identifies the person records of all people who have a work relationship in the enterprise

View All Organizations

Organization

Identifies all organizations in the enterprise

View All Positions

Position

Identifies all positions in the enterprise

View All Legislative Data Groups

LDG

Identifies all LDGs in the enterprise

View All Countries

Country

Identifies all countries in the FND_TERRITORIES table

View All Document Types

Document Type

Identifies all document types in the enterprise

View All Payrolls

Payroll

Identifies all payrolls in the enterprise

View All Payroll Flows

Payroll Flow

Identifies all payroll flows in the enterprise

View All Workforce Business Processes

Workforce Business Process

Identifies all registered workforce business processes in the enterprise

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:

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:

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.

Figure showing the relationships between
the components of an HCM 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:

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:

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.

An example organization hierarchy

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:

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.

Note

The data instance set from a person security profile also includes any person who has shared his or her information with the signed-on user. The only exception to this rule occurs for person security profiles in which Access to Own Record is the only security criterion.

If you do not:

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:

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.

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:

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.

Note

Managers other than line managers can access person records secured by manager hierarchy only if their roles have the appropriate security access. Providing this access to managers other than line managers is a security-setup task.

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.

A graphical summary of the people and
assignments in this line manager hierarchy.

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.

A graphical representation of Harry's
instance set in a person-level hierarchy.

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

A graphical representation of Monica's
instance set in a person-level hierarchy.

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

A graphical representation of Jane's
instance set in a person-level hierarchy.

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:

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.

A graphical representation of Harry's
instance set in an assignment-level manager hierarchy.

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.

A graphical representation of Monica's
instance set in an assignment-level manager hierarchy.

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

A graphical representation of Jane's
instance set in an assignment-level hierarchy.

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.

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:

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:

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:

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.

Note

Document type security profiles secure access to locally defined document types only. They do not 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.

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.

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.


Decisions to Consider

In This Example

What is the name of the HCM data role?

HR Specialist ABC Industrial - Sales Department

Which job role will the HCM data role include?

Human Resource Specialist

Which person records do users need to access?

Users need to access the managed person records of:

  • All workers in the sales department of ABC Industrial

  • The emergency contacts, beneficiaries, and dependents of all workers in the sales department of ABC Industrial

Which public person records do users need to access?

All

Which organizations do users need to access?

All organizations of all types in ABC Industrial

Which positions do users need to access?

Vice President of Sales and all subordinate positions in the position hierarchy of ABC Industrial

Which countries do users need to see in lists of countries?

All

Which LDGs do users need to access?

The LDG for the legal employer ABC Industrial. This LDG is identified in an existing LDG security profile.

Which document types do users need to access?

All

Which payrolls do users need to access?

Payrolls for the legal employer ABC Industrial. These payrolls are identified in an existing payroll security profile.

Which payroll flows do users need to access?

Payroll flows for the legal employer ABC Industrial. These payroll flows are identified in an existing payroll flow security profile.

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.

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.

Note

If a person's contact is also a worker, the contact's person record is excluded from the person security profile's data instance set, even when Include related contacts is selected, unless the contact's person record satisfies all other criteria in the security profile.

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:

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.