Search Results wf_role_display_name




Overview
Explore in AI Chat

Overview

APPS.UMX_CURRENT_ROLES_V is a reporting view in Oracle E-Business Suite that consolidates the effective role assignments for application users. It merges two distinct populations of role data: roles that are already active, sourced from WF_USER_ROLES, and roles that have been requested through the User Management (UMX) registration and provisioning workflow but are not yet finalized, sourced from UMX_REG_REQUESTS. The view therefore presents a unified, point-in-time picture of "current" role state per user, combining approved assignments with in-flight requests.

Because it exposes a normalized structure across both approved and pending role states, the view is frequently referenced by reporting, audit, and reconciliation logic. Many developers encounter it indirectly when searching for wf_role_display_name, a column that appears in the view's projection. In the documented definition, wf_role_display_name is included in the SELECT list alongside the more operationally significant wf_role_name.

Underlying Base Objects

The view is owned by APPS and is defined over four documented objects: FND_USER, UMX_REG_REQUESTS, WF_LOCAL_ROLES, and WF_USER_ROLES. The first three of these resolve through synonyms, while WF_USER_ROLES is itself a view. The definition is a three-way UNION ALL:

  • The first branch joins WF_USER_ROLES to FND_USER, matching user names directly or through a correlated lookup on wf_local_roles keyed by orig_system = 'HZ_PARTY'. It restricts to role_orig_system values of UMX or FND_RESP and partition_id IN (2,13), returning status_code = 'APPROVED' with a dummy reg_request_id of -1.
  • The second branch joins UMX_REG_REQUESTS to WF_LOCAL_ROLES for responsibility roles (orig_system = 'FND_RESP', partition_id = 2), returning pending or verifying requests whose effective dates are current.
  • The third branch performs the analogous join for orig_system = 'UMX' roles in partition_id = 13.

Both request branches filter to statuses VERIFYING, PENDING, or self-requested UNASSIGNED, and exclude expired requests or roles using nvl(... , sysdate + 1) > sysdate date guards.

Key Columns

  • REG_REQUEST_ID — the registration request identifier; -1 indicates an already-approved role rather than a pending request.
  • REG_SERVICE_CODE — the UMX registration service that generated the request.
  • STATUS_CODE — either APPROVED for active assignments or the request status (VERIFYING, PENDING, UNASSIGNED).
  • WF_ROLE_NAME — the internal role/responsibility name; this is the join key against WF_LOCAL_ROLES.
  • WF_ROLE_DISPLAY_NAME and WF_ROLE_DESCRIPTION — projected as null in all three branches; the view does not populate display text, so callers must join to WF_LOCAL_ROLES or FND_RESPONSIBILITY for display labels.
  • USER_ID and REQUESTED_BY_USER_ID — identify the affected user and the requesting user respectively.

Common Use Cases and Queries

The view is typically used to audit who currently holds which roles, or to track role provisioning in progress. A representative query lists current, approved roles for a user:

  • SELECT user_id, wf_role_name, status_code FROM apps.umx_current_roles_v WHERE status_code = 'APPROVED';
  • SELECT wf_role_name, status_code FROM apps.umx_current_roles_v WHERE user_id = :p_user_id;
  • SELECT status_code, COUNT(*) FROM apps.umx_current_roles_v GROUP BY status_code;

Because wf_role_display_name is returned as null, users who need descriptive labels should join the result to WF_LOCAL_ROLES on wf_role_name = nam to obtain display names, or to FND_RESPONSIBILITY for responsibility titles. This distinction explains why the column exists in the projection yet carries no data.