11g Release 1 (11.1.3)
Part Number E20378-01
Contents
Previous
Next
|
Oracle® Fusion
Applications Coexistence for HCM Implementation Guide 11g Release 1 (11.1.3) Part Number E20378-01 |
Contents |
Previous |
Next |
This chapter contains the following:
Role Provisioning and Deprovisioning: Explained
Creating Users and Provisioning Roles for HCM Coexistence: Explained
Synchronization of User and Role Information with Oracle Identity Management: How It Is Processed
A user's access to data and functions depends on the user's roles: users have one or more roles that enable them to perform the tasks required by their jobs or positions. Roles must be provisioned to users; otherwise, users have no access to data or functions.
Roles can be provisioned to users:
Automatically
Manually, using delegated administration:
Users such as line managers and human resource specialists can provision roles manually to other users.
Users can request roles for themselves.
For both automatic and manual role provisioning, you create a role mapping to identify when a user becomes eligible for a role.
Oracle Identity Management (OIM) can be configured to notify users when their roles change; notifications are not issued by default.
Data roles, abstract roles, and job roles can be provisioned to users. Roles available for provisioning include predefined roles, HCM data roles, and roles created using OIM.
A role is provisioned to a user automatically when at least one of the user's assignments satisfies the conditions specified in the relevant role-mapping definition. The provisioning occurs when the assignment is either created or updated. For example, when a person is promoted to a management position, the line manager role is provisioned automatically to the person if an appropriate role mapping exists. Any change to a person's assignment causes the person's automatically provisioned roles to be reviewed and updated as necessary.
Automatically provisioned roles are deprovisioned automatically as soon as a user no longer satisfies the role-mapping conditions. For example, a line manager role that is provisioned to a user automatically is deprovisioned automatically when the user ceases to be a line manager.
Automatically provisioned roles can be deprovisioned manually at any time.
Manually provisioned roles are deprovisioned automatically only when all of the user's work relationships are terminated; in all other circumstances, users retain manually provisioned roles until they are deprovisioned manually.
When a person's line manager is changed, the roles of both new and previous line managers are updated as necessary. For example, if the person's new line manager now satisfies the conditions in the role mapping for the line manager role, and the role is one that is eligible for autoprovisioning, then that role is provisioned automatically to the new line manager. Similarly, if the previous line manager no longer satisfies the conditions for the line manager role, then that role is deprovisioned automatically.
When a work relationship is terminated, all automatically provisioned roles for which the user does not qualify in other work relationships are deprovisioned automatically. Manually provisioned roles are deprovisioned automatically only if the user has no other work relationships; otherwise, the user retains all manually provisioned roles until they are deprovisioned manually.
Automatic deprovisioning can occur either as soon as the termination is submitted or approved or on the day after the termination date. The user who is terminating the work relationship selects the appropriate deprovisioning date.
Role mappings can provision roles to users automatically at termination. For example, the locally defined roles Retiree and Beneficiary could be provisioned to users at termination based on assignment status and person type values.
If a termination is later reversed, roles that were deprovisioned automatically at termination are reinstated and post-termination roles are deprovisioned automatically.
Automatic role provisioning and deprovisioning are based on current data. For a future-dated transaction, such as a future promotion, role changes are identified and role provisioning occurs on the day the changes take effect, not when the change is entered. The process Send Pending LDAP Requests identifies future-dated transactions and manages role provisioning and deprovisioning at the appropriate time. Note that such role-provisioning changes are effective as of the system date; therefore, a delay of up to 24 hours may occur before users in other time zones acquire the access for which they now qualify.
User access to data and functions is determined by abstract, job, and data roles, which are provisioned to users either automatically or manually. To enable a role to be provisioned to users, you define a relationship, known as a mapping, between the role and a set of conditions, typically assignment attributes such as department, job, and system person type. In a role mapping, you can select any role stored in the Lightweight Directory Access Protocol (LDAP) directory, including Oracle Fusion Applications predefined roles, roles created in Oracle Identity Management (OIM), and HCM data roles.
The role mapping can support:
Automatic provisioning of roles to users
Manual provisioning of roles to users
Role requests from users
Immediate provisioning of roles
A role is provisioned to a user automatically if:
At least one of the user's assignments satisfies all conditions associated with the role in the role mapping.
You select the Autoprovision option for the role in the role mapping.
For example, for the HCM data role Sales Manager Finance Department, you could select the Autoprovision option and specify the following conditions.
|
Attribute |
Value |
|---|---|
|
Department |
Finance Department |
|
Job |
Sales Manager |
|
Assignment Status |
Active |
The HCM data role Sales Manager Finance Department is provisioned automatically to users with at least one assignment that satisfies all of these conditions.
Automatic role provisioning occurs as soon as the user is confirmed to satisfy the role-mapping conditions, which can be when the user's assignment is either created or updated. The provisioning process also removes automatically provisioned roles from users who no longer satisfy the role-mapping conditions.
Note
The automatic provisioning of roles to users is effectively a request to OIM to provision the role. OIM may reject the request if it violates segregation-of-duties rules or fails a custom OIM approval process.
Users such as human resource (HR) specialists and line managers can provision roles manually to other users; you create a role mapping to identify roles that can be provisioned in this way.
Users can provision a role to other users if:
At least one of the assignments of the user who is provisioning the role (for example, the line manager) satisfies all conditions associated with the role mapping.
You select the Requestable option for the role in the role mapping.
For example, for the HCM data role Quality Assurance Team Leader, you could select the Requestable option and specify the following conditions.
|
Attribute |
Value |
|---|---|
|
Manager with Reports |
Yes |
|
Assignment Status |
Active |
Any user with at least one assignment that satisfies both of these conditions can provision the role Quality Assurance Team Leader manually to other users, who are typically direct and indirect reports.
If the user's assignment subsequently changes, there is no automatic effect on roles provisioned by this user to others; they retain manually provisioned roles until either all of their work relationships are terminated or the roles are manually deprovisioned.
Users can request roles when reviewing their own account information; you create a role mapping to identify roles that users can request for themselves.
Users can request a role if:
At least one of their own assignments satisfies all conditions associated with the role mapping.
You select the Self-requestable option for the role in the role mapping.
For example, for the Expenses Reporting role you could select the Self-requestable option and specify the following conditions.
|
Attribute |
Value |
|---|---|
|
Department |
ABC Department |
|
System Person Type |
Employee |
|
Assignment Status |
Active |
Any user with at least one assignment that satisfies all of these conditions can request the role. The user acquires the role either immediately or, if approval is required, once the request is approved. Self-requested roles are classified as manually provisioned.
If the user's assignment subsequently changes, there is no automatic effect on self-requested roles. Users retain manually provisioned roles until either all of their work relationships are terminated or the roles are manually deprovisioned.
When you create a role mapping, you can apply autoprovisioning from the role mapping itself.
In this case, all assignments and role mappings in the enterprise are reviewed. Roles are:
Provisioned immediately to all users who do not currently have roles for which they are eligible
Deprovisioned immediately from users who are no longer eligible for roles that they currently have
Immediate autoprovisioning from the role mapping enables bulk automatic provisioning of roles to a group of users who are identified by the role-mapping conditions. For example, if you create a new department after a merger, you can provision relevant roles to all users in the new department by applying autoprovisioning immediately.
To provision roles immediately to a single user, the user's line manager or an HR specialist can autoprovision roles from that user's account.
The names of role mappings must be unique in the enterprise. You are recommended to devise a naming scheme that reveals the scope of each role mapping. For example:
|
Name |
Description |
|---|---|
|
Autoprovisioned Roles Sales Department |
Mapping includes all roles provisioned automatically to anyone in the sales department |
|
Benefits Specialist Autoprovisioned |
Mapping defines the conditions for autoprovisioning the Benefits Specialist role |
|
Line Manager Requestable Roles |
Mapping includes all roles that a line manager can provision manually to direct and indirect reports |
Roles must be provisioned to users explicitly, either automatically or manually; no role is provisioned to a user by default. This topic provides some examples of typical role mappings to support automatic and manual role provisioning.
You want all employees in your enterprise to have the Employee role automatically when they are hired. In addition, employees must be able to request the Expenses Reporting role when they need to claim expenses. Few employees will need this role, so you decide not to provision it automatically to all employees.
You create a role mapping called All Employees and enter the following conditions.
|
Attribute |
Value |
|---|---|
|
System Person Type |
Employee |
|
Assignment Status |
Active |
In the role mapping you include the:
Employee role, and select the Autoprovision option
Expenses Reporting role, and select the Self-requestable option
You could create a similar role mapping for contingent workers called All Contingent Workers, where you would set the system person type to contingent worker.
Note
If the Employee and Contingent Worker roles are provisioned automatically, pending workers acquire them when their periods of employment or placements start. If they need roles before then, you create a separate role mapping for the pending worker system person type.
Any type of worker can be a line manager in the sales business unit. You create a role mapping called Line Manager Sales BU and enter the following conditions.
|
Attribute |
Value |
|---|---|
|
Business Unit |
Sales |
|
Assignment Status |
Active |
|
Manager with Reports |
Yes |
You include the Line Manager role and select the Autoprovision option. This role mapping ensures that the Line Manager role is provisioned automatically to any worker with at least one assignment that matches the role-mapping conditions.
In the same role mapping, you could include roles that line managers in this business unit can provision manually to other users by selecting the roles and marking them as requestable. Similarly, if line managers can request roles for themselves, you could include those in the same role mapping and mark them as self-requestable.
Retirees in your enterprise need a limited amount of system access to manage their retirement accounts. You create a role mapping called All Retirees and enter the following conditions.
|
Attribute |
Value |
|---|---|
|
System Person Type |
Retiree |
|
Assignment Status |
Inactive |
You include the locally defined role Retiree in the role mapping and select the Autoprovision option. When at least one of a worker's assignments satisfies the role-mapping conditions, the Retiree role is provisioned to that worker automatically.
Grade 6 sales managers in the sales department need the Sales Manager role. In addition, sales managers need to be able to provision the Sales Associate role to other workers. You create a role mapping called Sales Managers Sales Department and enter the following conditions.
|
Attribute |
Value |
|---|---|
|
Department |
Sales |
|
Job |
Sales manager |
|
Grade |
6 |
|
Assignment Status |
Active |
In the role mapping, you include the:
Sales Manager role, and select the Autoprovision option
Sales Associate role, and select the Requestable option
A user is created automatically for each worker record that you load into Oracle Fusion from your source application. User accounts are created and maintained in a Lightweight Directory Access Protocol (LDAP) directory local to Oracle Fusion by Oracle Identity Management (OIM). You must work with your service provider to configure items such as identity policy and password policy in OIM. Users have a user name and password that are specific to their use of Oracle Fusion applications.
The process for creating users and provisioning roles to them varies according to whether you are performing an initial or incremental data load.
To create users and provision roles to them during the initial data load, you:
Create the role provisioning rules required by your enterprise.
User access to functions and data is determined entirely by the roles that users have, and roles must be provisioned to users. To manage both automatic and manual provisioning of roles to users, you create role mappings. For example, you create role mappings to provision abstract roles, such as employee and line manager, automatically to all employees and line managers. If you create data roles for particular job roles, you must create role mappings to manage the provisioning of those roles to eligible users. A typical user has multiple roles. To create role mappings, you perform the Manage HCM Role Provisioning Rules task.
Note
If your initial data load includes large volumes of person and employment data, you are recommended to perform step 1 (this step) after step 3.
Load person and employment data.
For the initial data load, you perform the Oracle Fusion Functional Setup Manager task Load HCM Data for Coexistence.
Run the Send Pending LDAP Requests process.
This process sends bulk requests to OIM to create, suspend, and re-enable user accounts, as appropriate.
Apply autoprovisioning, using the Manage Role Mappings task, to assign all roles with the Autoprovision option selected to eligible workers.
Manually assign roles, as appropriate.
Roles identified in your role provisioning rules as Requestable can be assigned to other workers by managers and human resource specialists who satisfy the role mapping conditions. Workers who satisfy the role mapping conditions can request for themselves roles identified in your role provisioning rules as Self-requestable.
When you load person and employment data after the initial data load, the process for managing users and role provisioning is as follows:
Update role provisioning rules, if necessary.
The role mappings that you created for the initial data load may be sufficient; however, you are recommended to validate the existing mappings and make any changes before you perform an incremental data load.
Load person and employment data using the Load HCM Data task in the Data Exchange work area.
Run the Send Pending LDAP Requests process.
You can schedule this process to run automatically. For example, you could schedule this process to run daily.
Manually assign requestable roles, as appropriate.
Oracle Identity Management (OIM) maintains Lightweight Directory Access Protocol (LDAP) user accounts for users of Oracle Fusion Applications. OIM also stores the definitions of abstract, job, and data roles, and holds information about roles provisioned to users.
Most changes to user and role information are shared automatically and instantly by Oracle Fusion Human Capital Management (HCM) and OIM. In addition, two scheduled processes, Send Pending LDAP Requests and Retrieve Latest LDAP Changes, manage information exchange between Oracle Fusion HCM and OIM in some circumstances.
Send Pending LDAP Requests sends to OIM bulk requests and future-dated requests that are now active.
Retrieve Latest LDAP Changes requests from OIM changes that may not have arrived because of a failure or error, for example.
You are recommended to run the Send Pending LDAP Requests process at least daily to ensure that future-dated changes are identified and processed as soon as they take effect. Retrieve Latest LDAP Changes can also run daily, or less frequently if you prefer. For example, if you know that a failure has occurred between OIM and Oracle Fusion HCM, then you can run Retrieve Latest LDAP Changes to ensure that user and role information is synchronized.
When processing bulk requests, the batch size that you specify for the Send Pending LDAP Requests process is the number of requests to be processed in a single batch. For example, if you specify a batch size of 25, 16 batches of requests will be created and processed in parallel if there are 400 requests to be processed.
Synchronization of most user and role information between Oracle Fusion HCM and OIM occurs automatically. However, when you run Send Pending LDAP Requests to process future-dated or bulk requests, it sends to OIM:
Requests to create, suspend, and re-enable user accounts.
When a person record is created in Oracle Fusion HCM, OIM creates a user account automatically.
When all of a person's work relationships are terminated and the person has no roles, the person's user account is suspended automatically. If the person is subsequently rehired, the suspended account is automatically re-enabled.
Role provisioning and role deprovisioning changes for individual users.
Changes to relevant person attributes for individual users.
New and updated information about HCM data roles, which are created in Oracle Fusion HCM.
The process Retrieve Latest LDAP Changes sends to Oracle Fusion HCM:
Names of new user accounts.
When a person record is created in Oracle Fusion HCM, OIM creates a user account automatically and returns:
The user account name and password. If the user's primary work e-mail address was entered when the person record was created, then the user account name and password are returned to the user; otherwise, this information is returned to the primary work e-mail address of the user's line manager. (No notification is sent if the user has no line manager or the line manager has no primary work e-mail address.)
The globally unique identifier (GUID) associated with the LDAP directory user account, which is added automatically to the person record.
Latest information about abstract, job, and data roles.
OIM stores latest information about all abstract, job, and data roles, including HCM data roles. Oracle Fusion HCM maintains a local copy of all role names and types so that lists of roles presented in role mappings and elsewhere are up to date.
Note
New HCM data roles are available only when OIM has returned information about those roles to Oracle Fusion HCM.
Work e-mail addresses, if OIM owns the work e-mail address.
The values of the following person attributes are sent to OIM automatically whenever a person record is created and whenever any of these attributes is subsequently updated.
Person number
System person type from the person's primary assignment
Latest start date of the current period of service
The GUIDs of all of the person's managers
Work e-mail address, if Oracle Fusion HCM owns the work e-mail address
Work mobile phone number
Work phone number
Work FAX number
Both the display name and the following name components in all languages in which they have been created in the person record:
First name
Middle name
Last name
Name suffix
Both the formatted work-location address and the following components of the work-location address from the person's primary assignment:
Address line 1
City
State
Postal code
Country code
No personally identifiable information (PII) is sent from Oracle Fusion HCM to OIM.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
