Search Results wf_role_description

Overview

UMX_CURRENT_ROLES_V is a private view owned by the APPS schema in Oracle E-Business Suite, defined within the FND — Application Object Library product. Its stated purpose is to display roles and registration requests for a given user, consolidating two distinct categories of data into a single, query-friendly result set. The view is consumed internally by the User Management (UMX) subsystem rather than by end-user forms directly, and it is not intended as a public API surface. Because it merges approved role assignments held in the workflow directory with in-flight registration requests, it provides a unified picture of a user's current and pending role state, which is valuable for reconciliation, audit, and administrative reporting.

In the context of EBS 12.1.1 and 12.2.2, the view remains relevant because role provisioning continues to flow through the workflow directory and the UMX registration request queue. Administrators investigating a user's effective roles can query this view rather than joining WF_USER_ROLES and UMX_REG_REQUESTS manually.

Underlying Base Objects

The documented base objects are FND_USER, UMX_REG_REQUESTS, WF_LOCAL_ROLES, and WF_USER_ROLES, all exposed to APPS through synonyms except WF_USER_ROLES, which is itself a view. The view text is a three-branch UNION ALL:

• The first branch joins WF_USER_ROLES to FND_USER, returning already-approved roles with REG_REQUEST_ID of -1 and STATUS_CODE 'APPROVED'. It restricts to ROLE_ORIG_SYSTEM values 'UMX' or 'FND_RESP' and partition IDs 2 and 13.
• The second branch joins UMX_REG_REQUESTS to WF_LOCAL_ROLES for FND_RESP roles (partition 2), returning active requests that are unassigned, verifying, or pending.
• The third branch mirrors the second for UMX roles (partition 13), covering the same active status range.

Both request branches filter out expired requests using REQUESTED_END_DATE, and require the role itself to be currently valid via START_DATE and EXPIRATION_DATE.

Key Columns

• REG_REQUEST_ID — Identifier of the registration request; -1 signals an already-approved assignment.
• REG_SERVICE_CODE — The registration service that originated the request; NULL for approved rows.
• STATUS_CODE — 'APPROVED' for existing assignments, or 'UNASSIGNED', 'VERIFYING', or 'PENDING' for open requests.
• WF_ROLE_NAME — Internal workflow role name, the principal join key to WF_LOCAL_ROLES.
• USER_ID — The user the row pertains to. Note the aliasing: in the approved branch this is FND_USER.USER_ID, while in the request branches it carries REQUESTED_BY_USER_ID, so the column reflects the requesting party in pending rows.
• REQUESTED_BY_USER_ID — The user who submitted the request; NULL in the approved branch (aliased as TO_NUMBER(NULL)) and populated from UMX_REG_REQUESTS in the request branches.

Common Use Cases and Queries

A typical administrative query retrieves all roles and pending requests for a specific user, which is the scenario most often associated with the search term requested_by_user_id:

• SELECT user_id, wf_role_name, status_code, reg_request_id, requested_by_user_id FROM apps.umx_current_roles_v WHERE user_id = :p_user_id;
• Filtering open requests only: ... WHERE status_code IN ('UNASSIGNED','VERIFYING','PENDING');
• Identifying self-requested pending roles: ... WHERE requested_by_user_id = user_id;

These queries support access certification reviews, provisioning audits, and troubleshooting of stalled role requests. Because the view is private, consumers should treat its structure as subject to change across patches.