Oracle Workflow requires a directory service to provide information about the individuals and roles in your organization who may utilize Oracle Workflow functionality and receive workflow notifications. Oracle Workflow references this user and role information through the following views.

• WF_USERS - Individual users.

• WF_ROLES - Roles, which can have one or more users as members.

• WF_USER_ROLES - Associations of users with the roles of which they are members.

  Note: A role can contain only individual users as its members. It cannot contain another role. However, roles can be related to each other in a hierarchy so that users assigned to one role automatically inherit membership in its superior roles as well.

• WF_USER_ROLE_ASSIGNMENTS_V - Assignments of users to roles, both direct and inherited through role hierarchy relationships.

See: Workflow Directory Service Views.

Oracle Workflow provides a predefined directory service for you that is implemented by default during installation, with directory service views for users and roles from the unified Oracle E-Business Suite environment. See: Setting Up a Directory Service for Oracle Workflow.

You can also create your own directory service by defining custom views with the required columns. However, note that only the predefined directory service provided by Oracle Workflow is supported by Oracle. See: Oracle Workflow Support Policy.

Oracle Workflow provides local directory repository tables called WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES. These tables should always be included in any implementation of the WF_USERS, WF_ROLES, and WF_USER_ROLES views.

• WF_LOCAL_ROLES stores role information, including a user flag to mark those roles that also represent individual users. This table contains columns similar to those required in the WF_USERS and WF_ROLES views.

• WF_LOCAL_USER_ROLES stores information about the associations of users with roles. This table contains columns similar to those required in the WF_USER_ROLES view.

Oracle Workflow also provides tables to support extended directory service features.

• WF_LOCAL_ROLES_TL stores translated display name and description values for multiple language support (MLS) in the WF_USERS and WF_ROLES views.

• WF_ROLE_HIERARCHIES stores information about the hierarchical relationships between roles.

• WF_USER_ROLE_ASSIGNMENTS stores information about the direct and inherited assignments of users to roles.

The Workflow local tables store denormalized user and role information originating from various other Oracle E-Business Suite modules, so that the directory service views can access this information with good performance. You can also use these tables to store ad hoc users and roles by calling the appropriate Workflow directory service PL/SQL APIs.

You should periodically purge ad hoc users and roles from the Workflow local tables after they have expired in order to improve performance. See: Directory.

For more information, see: Workflow Directory Service APIs, Ad Hoc Users and Roles, and Oracle Workflow Security.

   Setting Up a Directory Service for Oracle Workflow:

Oracle Workflow uses a directory service model in which denormalized information is maintained in the Workflow local tables for performance gain. The Workflow local tables store user and role information originating from various other Oracle E-Business Suite modules, as well as ad hoc users and roles, so that the WF_USERS, WF_ROLES, WF_USER_ROLES, and WF_USER_ROLE_ASSIGNMENTS_V views can access this information with good performance. Oracle E-Business Suite ensures synchronization is maintained between the user and role information stored in application tables by the source modules and the information stored in the Workflow local tables.

Directory Service Views

The predefined WF_USERS, WF_ROLES, WF_USER_ROLES, and WF_USER_ROLE_ASSIGNMENTS_V directory service views for Oracle Workflow are based solely on the Workflow local tables where the denormalized information is stored. These view definitions are automatically created for you during installation. See: Workflow Directory Service Views.

• WF_USERS is based on WF_LOCAL_ROLES where the user flag is set to Y and on WF_LOCAL_ROLES_TL.

• WF_ROLES is based on WF_LOCAL_ROLES and on WF_LOCAL_ROLES_TL.

• WF_USER_ROLES is based on WF_LOCAL_USER_ROLES.

• WF_USER_ROLE_ASSIGNMENTS_V is based on WF_USER_ROLE_ASSIGNMENTS.

The only roles in WF_LOCAL_ROLES that are marked as individual users with the user flag set to Y are roles that represent Oracle E-Business Suite users, originating from the FND_USER table, roles that represent Oracle Trading Community Architecture (TCA) person parties, roles that represent TCA contacts (relationship parties), or roles that represent ad hoc users. Records originating from other application tables are treated solely as roles, with the user flag set to N. The WF_LOCAL_USER_ROLES table is used to associate Oracle E-Business Suite users, TCA person parties, and TCA contacts with roles defined by other applications.

The WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables are partitioned by the originating system within Oracle E-Business Suite that was the source of the denormalized information. This partitioning provides faster data access and also allows each originating system to be synchronized with the Workflow local tables individually. Each table also includes a separate partition that contains ad hoc users and roles as well as data from any system that does not have its own partition.

The partition information for each originating system is stored in the WF_DIRECTORY_PARTITIONS table. There are partitions for the following systems:

• WF_LOCAL_ROLES - Ad hoc users and roles, as well as data from any originating system that does not have its own partition

• FND_USR - FND users, which may or may not be linked to Oracle Human Resources people

• FND_RESP - FND responsibilities

• PER_ROLE - HR people

• POS - HR positions

• AMV_APPR - MarketView approvals

• AMV_CHN - MarketView channels

• ENG_LIST - Engineering approval list

• HZ_GROUP - TCA groups

• HZ_PARTY - TCA person parties and contacts

• GBX - Federal HR group boxes

• HTB_SEC - Healthcare

• PQH_ROLES - Position Control roles

• UMX - User Management roles

See: Ad Hoc Users and Roles.

Synchronizing Workflow User and Role Information

For each Oracle E-Business Suite module that is a source of Oracle Workflow user and role information, the information stored in the source application tables is synchronized with the denormalized information in the Workflow local tables. The Workflow local synchronization APIs are used to perform this synchronization.

Oracle Workflow automatically performs an initial synchronization of the user and role information in all the related originating systems during installation. Subsequently, each Oracle E-Business Suite module that stores user and role information in its application tables automatically synchronizes that information with the information in the Workflow local tables on an incremental basis, using the Workflow local synchronization APIs.

Role Hierarchies

Roles can be related to each other in a hierarchy so that users assigned to one role automatically inherit membership in its superior roles as well. Role hierarchies enable role-based access control in Oracle E-Business Suite.

For example, a company could define a role hierarchy with three roles: sales manager, sales representative, and employee. A user with the sales manager role automatically inherits the sales representative role, and a user with the sales representative role automatically inherits the employee role. If user A is assigned directly to the sales representative role, then user A will also have an inherited assignment to the employee role. If user B is assigned directly to the sales manager role, user B will also have inherited assignments to both the sales representative role and the employee role.

The role to which a user is directly assigned is the assigning role for that assignment and for all other assignments that the user inherits through that role's hierarchy. For instance, in the previous example, for user A the sales representative role is the assigning role for both the sales representative assignment and the employee assignment. For user B, the sales manager role is the assigning role for the sales manager assignment, the sales representative role assignment, and the employee role assignment.

Oracle Workflow stores hierarchical relationships between roles in the WF_ROLE_HIERARCHIES table. Oracle Workflow also stores denormalized information about direct and inherited assignments of users to roles in the WF_USER_ROLE_ASSIGNMENTS table for performance gain. If a user is associated with a certain role through more than one direct or inherited assignment, the WF_USER_ROLE_ASSIGNMENTS table tracks which assignments are currently valid and expires the user/role association only when all assignments have ended.

The inheritance of roles is based on the role relationships stored in the the WF_ROLE_HIERARCHIES table. As long as a role relationship exists in this table, a user assigned to a role will inherit both expired and unexpired roles in that role's hierarchy.

The start and end dates between which an assignment is valid depend on the effective dates of the following:

• The user

• The role being assigned to the user

• The assigning role

  • For a directly assigned role, the assigning role is this role itself.

  • For an inherited role, the assigning role is the directly assigned role through which this role is inherited.

• The assignment

The user, the assigned role, and the assigning role must all be active, that is, unexpired, in order for the assignment to be valid. The assignment does not become valid until all three are active, and if any of the three expires, the assignment is no longer valid. Additionally, the assignment is only valid as of the date it was created.

Validating Directory Service Information

You can run a diagnostic test through Oracle Diagnostics Framework to check that there are no duplicate roles in the WF_LOCAL_ROLES table. See: Oracle Workflow Diagnostic Tests.

If you encounter inconsistencies in your directory service information, Oracle Support may direct you to run the Workflow Directory Services User/Role Validation concurrent program (FNDWFDSURV) to validate and correct the information about user/role associations. You should also investigate the cause of any inconsistencies. Use Standard Request Submission to run this program, specifying the following parameters.

• Batch size - The number of records to process in one transaction before the program commits data. If your resources allow, you can increase this value to enhance performance. The default value is 10,000 records.

• User name - To validate user/role associations only for a particular user, specify the user name. Leave this parameter blank to perform validation for all users.

• Role name - To validate user/role associations only for a particular role, specify the role name. Leave this parameter blank to perform validation for all roles.

  Note: If you specify both a user name and a role name, the program validates only user/role associations linking that user with that role. To validate all user/role associations, leave both parameters blank.

• Fix dangling users - Select Yes to check that all users and roles referenced by user/role associations exist in the WF_LOCAL_ROLES table. If the user or role or both are missing for any user/role association, the program removes that user/role association from the WF_LOCAL_USER_ROLES table. Select No to skip this check. The default value is No.

• Add missing user/role assignments - Select Yes to check that all user/role associations in the WF_LOCAL_USER_ROLES table have corresponding user/role assignments in the WF_USER_ROLE_ASSIGNMENTS table and add any missing direct assignments. Select No to skip this check. The default value is No.

• Update Who columns in WF tables - Select No to preserve the existing values in the LAST_UPDATED_BY and LAST_UPDATE_DATE standard Who columns when the program updates corrupt records in the Workflow directory service tables. Select Yes if you want the program to update the standard Who columns. The recommended value, which is also the default value, is No.

• Number of Parallel Processes - Specify the number of parallel processes to use when running the program. By default, the number of processes to use is the lower of the database parameters parallel_max_servers and cpu_count. You can optionally specify a lower number of processes to avoid temporary space issues.

See: Running Reports and Programs.

   Workflow Directory Service Views:

Oracle Workflow relies on views named WF_USERS, WF_ROLES, WF_USER_ROLES, and WF_USER_ROLE_ASSIGNMENTS_V to reference user and role information. Other views provide further access to Workflow directory service data, including WF_ALL_ROLES_VL, WF_ALL_USER_ROLES, and WF_ALL_USER_ROLE_ASSIGNMENTS. These directory service views for the unified Oracle E-Business Suite environment are automatically defined for you during installation.

You can also create your own directory service by defining custom views with the required columns. However, note that only the predefined directory services provided by Oracle Workflow are supported by Oracle. See: Oracle Workflow Support Policy.

If you create your own custom view definitions:

• Each individual user identified by WF_USERS must also appear in the WF_ROLES view as a role.

• You should set the user flag in the underlying tables to Y for all the roles that also represent individual users, and set the user flag to N for all other roles.

• You should include the WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES tables in the view definitions. You can optionally also include the WF_LOCAL_ROLES_TL table for multiple language support.

• You should avoid selecting from DUAL to incorporate additional users and roles into the directory service views as this allows you to violate the unique constraint on certain columns of the views and reduces performance with unnecessary joins between the 'select from DUAL' statements.

• To take advantage of unique indexes when querying users, make sure you initially enter the usernames in your database in uppercase only. Forcing the usernames to uppercase in your view definition results in poor performance when accessing these views.

• You should run the script wfdirchk.sql to validate your directory service data model. This script is located in the $FND_TOP/sql directory. See: Wfdirchk.sql.

WF_USERS

The WF_USERS view references information about the individuals in your organization who may utilize Oracle Workflow functionality or receive workflow notifications.

The WF_USERS view must contain the following required columns:

• Name - The internal name of the user as referenced by the Workflow Engine and Notification System. For example, an internal name for a user can be MBEECH or 009, where 009 represents the user's employee ID.

  Important: If you define custom views, the Name column must be sourced from a column that is no longer than 320 characters, and it is recommended that the internal name be all uppercase. If your source table does not have a column that meets these criteria, DO NOT use string functions to force these restrictions. Instead, define the Name column to be <orig_system>:<orig_system_id> so that Oracle Workflow can reference the original base table where users are stored and a unique user in that table. For example, PER_PEOPLE:009 could represent a user whose employee ID is 009 and whose record is stored in a personnel table called PER_PEOPLE.

• Display_Name - The display name of the user. An example of a display name can be 'Beech, Matthew'.

• Description - An optional description of the user.

• Notification_Preference - The method by which this user prefers to receive notifications. A value of MAILTEXT, MAILHTML, MAILHTM2, or MAILATTH allows users to receive and respond to notifications by plain text e-mail, HTML-formatted e-mail with attachments, HTML-formatted e-mail without attachments, or by plain text e-mail with HTML attachments, respectively. A value of QUERY allows users to query notifications from the Worklist Web page. A value of DISABLED indicates that the e-mail address on record for the user is invalid, so no e-mail notifications will be sent; meanwhile the user can only query notifications from the Worklist Web page. Finally, a value of SUMMARY or SUMHTML allows users to receive periodic e-mail summaries of their open notifications. However, to respond to the individual notifications, they must view the notification in the Worklist Web pages. See: Overview of Notification Handling and Notification Preferences.

  Note: A notification preference of MAILTEXT, MAILHTML, MAILHTM2, or MAILATTH also allows users to view their notifications in the Worklist Web pages.

  Note: If no notification preference is provided by the originating system, the notification preference is set to MAILHTML by default.

  Note: If you define custom views, you can map the Notification_Preference column over the Oracle Workflow preferences table using the statement below. The benefit of doing so is that you can then globally set the default notification preference for all users in your enterprise using the Workflow Configuration page, and let individual users override that default value by changing their notification preference in the Preferences page in Oracle E-Business Suite. See: Setting Global User Preferences and get_pref.

  NVL(wf_pref.get_pref(USR.USER_NAME,'MAILTYPE'), 'MAILHTML')
  

• Language - The value of the database NLS_LANGUAGE initialization parameter that specifies the default language-dependent behavior of the user's notification session. The Language column is required and cannot be left null. Refer to your Oracle Database user's guide or installation manual for the list of supported language conventions.

  Note: For roles that are Oracle E-Business Suite users marked with an originating system of FND_USR or PER, Oracle Workflow uses the GetRoleInfo() procedure to find the language for a user, rather than querying this column in the directory service views. GetRoleInfo() by default retrieves the language value from the ICX: Language profile option for that Oracle E-Business Suite user.

  However, if the WF_PREFERENCE resource token is defined and set to FND, then the GetRoleInfo() procedure obtains the language value from the Oracle Workflow preferences table instead.

  Note: If you define custom views, and the WF_PREFERENCE resource token is set to FND, then you can map the Language column over the Oracle Workflow preferences table using the statement below. The benefit of doing so is that you can then globally set the default language for all users in your enterprise and let individual users override that default value by changing their language preference. See: Setting Global User Preferences and get_pref.

  NVL(wf_pref.get_pref(USR.USER_NAME,'LANGUAGE'), <default_language>)
  

  Important: Ensure that the e-mail templates used by notification mailers to send notifications have been translated by Oracle to the language you wish to set. The standard e-mail templates are delivered in a file called wfmail.wft under the subdirectory $FND_TOP/import/<lang>. You can check the appropriate language subdirectory to verify if the templates have been translated to the language you wish to set. See: Modifying Your Message Templates.

• Territory - The value of the database NLS_TERRITORY initialization parameter that specifies the default territory-dependent formatting used in the user's notification session. The Territory column is required and cannot be left null. Refer to your Oracle Database user's guide or installation manual for the list of supported territory conventions.

  Note: For roles that are Oracle E-Business Suite users marked with an originating system of FND_USR or PER, Oracle Workflow uses the GetRoleInfo() procedure to find the territory for a user, rather than querying this column in the directory service views. GetRoleInfo() by default retrieves the territory value from the ICX: Territory profile option for that Oracle E-Business Suite user.

  However, if the WF_PREFERENCE resource token is defined and set to FND, then the GetRoleInfo() procedure obtains the territory value from the Oracle Workflow preferences table instead.

  Note: If you define custom views, and the WF_PREFERENCE resource token is set to FND, then you can map the Territory column over the Oracle Workflow preferences table using the statement below. The benefit of doing so is that you can then globally set the default territory for all users in your enterprise and let individual users override that default value by changing their territory preference. See: Setting Global User Preferences and get_pref.

  NVL(wf_pref.get_pref(USR.USER_NAME,'TERRITORY'), <default_territory>)
  

• Email_Address - A valid electronic mail address for this user or a mail distribution list defined by your electronic mail system. You can enter more than one e-mail address for a user; in this case Oracle Workflow sends e-mail notifications for the user to all addresses stored in this column. Enter the e-mail addresses separated by commas. Do not include spaces between the addresses. The maximum length for the combined list of e-mail addresses in this column is 320 characters.

• Fax - A fax number for the user.

• Orig_System - A code that you assign to originating system, which is the directory repository that this view is ultimately based on. For example, if this view is based on the personnel data stored in a Human Resource Management System, Orig_System can be defined as PER.

• Orig_System_ID - The primary key that identifies the user in this repository system. For example, Orig_System_ID can be defined as the value stored in a column called PERSON_ID in a Human Resources database table called PER_PEOPLE.

• Parent_Orig_System - An optional code for the originating system of an entity that you want to mark as being related to this user. For example, a supplier could be marked as the parent of a supplier site.

• Parent_Orig_System_ID - The primary key that identifies the parent entity in the parent originating system.

  Note: If no parent information is provided, the Parent_Orig_System and Parent_Orig_System_ID default to the user's own Orig_System and Orig_System_ID, respectively.

• Start_Date - The date at which the user becomes valid in the directory service.

• Status - The availability of the user to participate in a workflow process. The possible statuses are: active (ACTIVE), unavailable for an extended period (EXTLEAVE), permanently unavailable (INACTIVE), and temporarily unavailable (TMPLEAVE). These statuses are also stored in the lookup type called WFSTD_AVAILABILITY_STATUS.

• Expiration_Date - The date at which the user is no longer valid in the directory service. After this date, the user will no longer appear in the seeded WF_USERS view.

• Owner_Tag - A code to identify the program or application that owns the information for this user.

WF_ROLES

The WF_ROLES view references information about all the roles in your organization who may utilize Oracle Workflow functionality or receive workflow notifications. This view must contain the following required columns pertaining to the roles in your repository. Those columns that are preceded by an asterisk (*) are similar to the corresponding columns described for the WF_USERS view.

• Name - The internal name of the role as referenced by the Workflow Engine and Notification System.

  Important: If you define custom views, the Name column must be sourced from a column that is no longer than 320 characters, and it is recommended that the internal name be all uppercase. If your source table does not have a column that meets these criteria, DO NOT use string functions to force these restrictions. Instead, define the Name column to be <orig_system>:<orig_system_id> so that Oracle Workflow can reference the original base table where roles are stored and a unique role in that table. For example, "PER_POSITION:009" could represent a position whose ID is 009 and whose record is stored in the personnel table called PER_POSITION.

• *Display_Name

• *Description

• *Notification_Preference

• *Language

• *Territory

• Email_Address - If the e-mail address is null for a given role, notification mailers send an individual e-mail to each user within the role.

• *Fax

• *Orig_System

• *Orig_System_ID

• *Parent_Orig_System

• *Parent_Orig_System_ID

• *Start_Date

• *Status

• Expiration_Date - The date at which the role is no longer valid in the directory service. After this date, the role will no longer appear in the seeded WF_ROLES view.

• *Owner_Tag

WF_USER_ROLES

The WF_USER_ROLES view is an intersection of the users and roles in WF_USERS and WF_ROLES, showing which users are members of which roles.

The WF_USER_ROLES view must contain the following required columns:

• User_Name - The internal name of the user as listed in the view WF_USERS.

• Role_Name - The internal name of the role as listed in the view WF_ROLES.

• User_Orig_System - A code that you assign to the user directory repository as listed in the view WF_USERS.

• User_Orig_System_ID - The primary key that identifies the user in the user directory repository as listed in the view WF_USERS.

• Role_Orig_System - A code that you assign to the role directory repository as listed in the view WF_ROLES.

• Role_Orig_System_ID - The primary key that identifies the role in the role directory repository as listed in the view WF_ROLES.

• Start_Date - The date at which the association of this user with this role becomes valid in the directory service.

• Expiration_Date - The date at which the association of this user with this role is no longer valid in the directory service. After this date, the user and role association will no longer appear in the seeded WF_USER_ROLES view.

• Assignment_Type - A code indicating how the user was assigned to membership in this role.

  • D - The user was directly assigned to this role.

  • I - The user inherited this role through membership in another role.

  • B - The user has both direct and inherited assignments to this role.

• Parent_Orig_System - An optional code for the originating system of an entity that you want to mark as being related to this user/role association.

• Parent_Orig_System_ID - The primary key that identifies the parent entity in the parent originating system.

WF_USER_ROLE_ASSIGNMENTS_V

The WF_USER_ROLE_ASSIGNMENTS_V view is an intersection of the users and roles in WF_USERS and WF_ROLES, that tracks how assignments of users to roles are made directly or inherited through role hierarchy relationships. The view shows only currently active assignments.

The WF_USER_ROLE_ASSIGNMENTS_V view contains the following columns:

• User_Name - The internal name of the user as listed in the view WF_USERS.

• Role_Name - The internal name of the role as listed in the view WF_ROLES.

• Assigning_Role - The role from which the user is inheriting assignment to this role.

• Start_Date - The date at which the assignment of this user to this role becomes valid in the directory service.

• End_Date - The date at which the assignment of this user to this role is no longer valid in the directory service.

• Assignment_Type - The way in which the user was assigned to membership in this role, either DIRECT or INHERITED.

WF_ALL_ROLES_VL

The WF_ALL_ROLES_VL view contains role information similar to the WF_ROLES view. However, WF_ALL_ROLES_VL includes all roles, whether not yet valid, currently valid, or expired.

The WF_ALL_ROLES_VL view contains the following columns:

• Name - The internal name of the role.

• Display_Name - The display name of the role.

• Description - An optional description of the role.

• Notification_Preference - The method by which this role prefers to receive notifications.

• Language - The value of the database NLS_LANGUAGE initialization parameter that specifies the default language-dependent behavior of the role's notification session.

• Territory - The value of the database NLS_TERRITORY initialization parameter that specifies the default territory-dependent formatting used in the role's notification session.

• Email_Address - A valid electronic mail address for this role.

• Fax - A fax number for the role.

• Orig_System - A code that you assign to originating system on which this view is ultimately based.

• Orig_System_ID - The primary key that identifies the role in the originating system.

• Start_Date - The date at which the role becomes valid in the directory service.

• Status - The availability of the role to participate in a workflow process. The possible statuses are: active (ACTIVE), unavailable for an extended period (EXTLEAVE), permanently unavailable (INACTIVE), and temporarily unavailable (TMPLEAVE). These statuses are also stored in the lookup type called WFSTD_AVAILABILITY_STATUS.

• Expiration_Date - The date at which the role is no longer valid in the directory service.

• Owner_Tag - A code to identify the program or application that owns the information for this role.

• Created_By - Standard Who column.

• Creation_Date - Standard Who column.

• Last_Updated_By - Standard Who column.

• Last_Update_Date - Standard Who column.

• Last_Update_Login - Standard Who column.

WF_ALL_USER_ROLES

The WF_ALL_USER_ROLES view contains user/role association information similar to the WF_USER_ROLES view. However, WF_ALL_USER_ROLES includes all user/role associations, whether not yet valid, currently valid, or expired.

The WF_ALL_USER_ROLES view contains the following columns:

• User_Name - The internal name of the user.

• Role_Name - The internal name of the role .

• User_Orig_System - A code that you assign to the user directory repository.

• User_Orig_System_ID - The primary key that identifies the user in the user originating system.

• Role_Orig_System - A code that you assign to the role directory repository.

• Role_Orig_System_ID - The primary key that identifies the role in the role originating system.

• Parent_Orig_System - An optional code for the originating system of an entity that you want to mark as being related to this user/role association.

• Parent_Orig_System_ID - The primary key that identifies the parent entity in the parent originating system.

• Assignment_Type - A code indicating how the user was assigned to membership in this role.

  • D - The user was directly assigned to this role.

  • I - The user inherited this role through membership in another role.

  • B - The user has both direct and inherited assignments to this role.

• Start_Date - The date at which the association of this user with this role becomes valid in the directory service.

• Expiration_Date - The date at which the association of this user with this role is no longer valid in the directory service.

• Owner_Tag - A code to identify the program or application that owns the information for the association of this user with this role.

• Created_By - Standard Who column.

• Creation_Date - Standard Who column.

• Last_Updated_By - Standard Who column.

• Last_Update_Date - Standard Who column.

• Last_Update_Login - Standard Who column.

WF_ALL_USER_ROLE_ASSIGNMENTS

The WF_ALL_USER_ROLE_ASSIGNMENTS view contains information about how assignments of users to roles are made directly or inherited through role hierarchy relationships, similar to the WF_USER_ROLE_ASSIGNMENTS_V view. However, WF_ALL_USER_ROLE_ASSIGNMENTS includes all user/role assignments, whether not yet valid, currently valid, or expired.

The WF_ALL_USER_ROLE_ASSIGNMENTS view contains the following columns:

• User_Name - The internal name of the user.

• Role_Name - The internal name of the role .

• Assigning_Role - The role from which the user is inheriting assignment to this role.

• Start_Date - The date at which the assignment of this user to this role becomes valid in the directory service.

• End_Date - The date at which the assignment of this user to this role is no longer valid in the directory service.

• Assignment_Type - The way in which the user was assigned to membership in this role, either DIRECT or INHERITED.

• Created_By - Standard Who column.

• Creation_Date - Standard Who column.

• Last_Updated_By - Standard Who column.

• Last_Update_Date - Standard Who column.

• Last_Update_Login - Standard Who column.