Search Results fnd_user_preferences




Overview
Explore in AI Chat

Overview

FND_USER_PREFERENCES is a runtime configuration table in the Oracle E-Business Suite Application Object Library (FND) product, owned by the APPLSYS schema. It stores per-user, per-module preference settings that govern how the EBS application behaves for an individual user session, such as default values, display options, and personalization flags. The table is present and valid in both EBS 12.1.1 and 12.2.2, and its structure is unchanged between the two releases: four documented columns and a composite primary key.

From a Data Vault modeling perspective, the ETRM metadata classifies this object as satellite-leaning based on its foreign key structure. This is offered as a heuristic modeling suggestion: FND_USER_PREFERENCES hangs off a single parent (FND_USER) and records descriptive, context-dependent attributes rather than defining business entities or resolving many-to-many relationships. In warehouse terms it behaves as a descriptive satellite keyed by user identity and preference context, rather than as a hub or a link.

Key Information Stored

The table contains only four documented columns, and together they form a compact key-value structure for user preferences.

  • USER_NAME — The EBS user login name. This is the business identifier of the user and is the leading column of both the primary key and the foreign key to FND_USER. It links a preference record to a specific application user.
  • MODULE_NAME — The functional module or application context to which the preference applies. It scopes preferences so that the same preference name can hold independent values per module.
  • PREFERENCE_NAME — The name of the individual preference setting being stored (for example, a display flag or default option). Together with USER_NAME and MODULE_NAME it uniquely identifies a preference record.
  • PREFERENCE_VALUE — The actual value assigned to the named preference for that user and module. This is the payload column; it is the descriptive attribute that changes as users adjust their settings.

The surrogate identifier in the documentation is the composite primary key FND_USER_PREFERENCES_PK, defined on (USER_NAME, MODULE_NAME, PREFERENCE_NAME). A unique index, FND_USER_PREFERENCES_U1, is documented on the same three columns, confirming this triplet as the business-key candidate that guarantees one value per user, module, and preference. There is no single-column surrogate key; the natural business key and the primary key coincide. The single foreign key, FND_USER_PREFERENCES.USER_NAME, references FND_USER.

Common Use Cases and Queries

Typical uses center on auditing and troubleshooting user personalization. Common scenarios include diagnosing why a form or page behaves differently for one user, migrating preferences between environments, and reporting on personalization coverage across the user base.

  • Retrieve all preferences for a specific user: SELECT MODULE_NAME, PREFERENCE_NAME, PREFERENCE_VALUE FROM APPLSYS.FND_USER_PREFERENCES WHERE USER_NAME = :user_name;
  • Find every user who has set a particular preference: SELECT USER_NAME, PREFERENCE_VALUE FROM APPLSYS.FND_USER_PREFERENCES WHERE MODULE_NAME = :module AND PREFERENCE_NAME = :pref;
  • Audit orphaned preferences by validating against the user repository: join to FND_USER on USER_NAME to detect records whose parent user no longer exists.
  • Report preference distribution for change impact analysis, grouping by MODULE_NAME and PREFERENCE_NAME to see which settings are widely used.

Because the table is small and its unique index is fully covered by the primary key, queries filtering on USER_NAME are efficient. Purge scripts should target preference rows only after confirming the associated user is obsolete; deleting a user typically cascades interest to these satellite records.

Related Objects

The following objects are most significant in relation to FND_USER_PREFERENCES:

  • FND_USER — The parent entity. Joined on FND_USER_PREFERENCES.USER_NAME = FND_USER.USER_NAME. This is the sole documented foreign key and the primary integration point.
  • FND_USER_PREFERENCES_PK — The composite primary key constraint enforcing uniqueness of (USER_NAME, MODULE_NAME, PREFERENCE_NAME).
  • FND_USER_PREFERENCES_U1 — The unique index backing the business key, equivalent in scope to the primary key columns.
  • FND_USER_RESP_GROUPS — Related user-level configuration that, combined with preferences, defines effective user behavior; joins on USER_NAME.
  • FND_PROFILE_OPTIONS / FND_PROFILE_OPTION_VALUES — Profile option infrastructure that frequently interacts with user preference settings at runtime, joined on USER_NAME where user-level profiles are stored.

These relationships confirm the table's role as a dependent satellite of FND_USER rather than an independent business entity. No other documented foreign keys or dependent objects exist in the supplied metadata, so joins beyond FND_USER should be validated against the active schema before use in production reporting.