Search Results fnd_user_view

Overview

FND_USER_VIEW is a database view owned by the APPS schema within the FND — Application Object Library product of Oracle E-Business Suite. According to the ETRM metadata, the view is marked with a status of VALID, though the documented description explicitly declares that it is obsolete. The description states: "This view is obsolete and should not be referenced by new code. It remains in the datamodel until all references to it can be removed."

In practical terms, FND_USER_VIEW presents a narrow, denormalized projection of the core application user repository. It exposes a small subset of columns from the underlying FND_USER base table, giving consumers read-only visibility into user identity, authentication foundation data, and validity dating. Because the view is obsolete, its role in current Oracle EBS reporting and integration is legacy in nature. It should be treated as a compatibility object that persists only to avoid breaking pre-existing custom code, concurrent programs, or integration scripts that were written against it in earlier releases. The recommendation for any new development is to query FND_USER directly rather than through this view. This guidance is consistent across both Oracle EBS 12.1.1 and 12.2.2, where the object remains unchanged in purpose.

Underlying Base Objects

The view is defined over a single base object: the FND_USER table. The documented view text is a straightforward SELECT across that table:

• SELECT USER_ID, USER_NAME, ENCRYPTED_FOUNDATION_PASSWORD, START_DATE, END_DATE FROM FND_USER

The ETRM metadata lists FND_USER as a referenced base object, resolved through a synonym in the APPS schema. Because the view contains no joins, aggregations, filters, or transformations, it is a pure pass-through projection. Every row in FND_USER_VIEW corresponds to one row in FND_USER, and no additional business logic is applied. This means the view inherits all of the security, integrity, and performance characteristics of the base table while offering none of the richer column set that FND_USER provides. The synonym resolution means that references to APPS.FND_USER_VIEW ultimately depend on the APPS.FND_USER table being present and valid in the same schema context.

Key Columns

The documented column list is limited to five attributes, each of which maps directly to a column in FND_USER:

• USER_ID — The unique numeric primary key identifying an application user. It is the standard foreign key used throughout EBS to associate transactions, responsibilities, and audit records with a specific user.
• USER_NAME — The login name of the application user. This is the human-readable identifier used during authentication and referenced in audit trails.
• ENCRYPTED_FOUNDATION_PASSWORD — The stored, encrypted foundation password value for the user. This is sensitive authentication data and should be treated as confidential; exposure in reports or extracts represents a security risk.
• START_DATE — The date from which the user record becomes effective.
• END_DATE — The date on which the user record ceases to be effective. A null value typically indicates an open-ended, active user.

Notably, the view omits many attributes available in FND_USER, including the employee association, email address, and last logon information. Consumers requiring these fields must query the base table.

Common Use Cases and Queries

Because the view is obsolete, the only defensible use cases are maintenance of legacy code and read-only lookups where the limited column set is sufficient. A typical query retrieves active users within an effective date range:

• SELECT user_id, user_name, start_date, end_date FROM apps.fnd_user_view WHERE SYSDATE BETWEEN start_date AND NVL(end_date, SYSDATE);

For integration scripts that only need to map a login name to a user identifier, the view serves as a lighter alternative to the full table:

• SELECT user_id FROM apps.fnd_user_view WHERE user_name = :p_user_name;

Existing code that selects the encrypted password column should be reviewed and migrated, since exposing authentication data is generally inadvisable. For all new reporting and integration work in 12.1.1 or 12.2.2, developers should query FND_USER directly, which provides the complete and supported column set. Queries against FND_USER_VIEW should be considered technical debt to be eliminated during upgrade or remediation cycles.