Search Results fnd_user_preferences_u1

Overview

APPLSYS.FND_USER_PREFERENCES is an Oracle E-Business Suite transactional table that stores user-specific preference settings referenced by individual application modules. Each row associates a preference name and value with a specific user and the module that consumes the setting. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10 and is maintained under the FND design data FND.FND_USER_PREFERENCES. Because it captures descriptive, context-dependent attributes tied to a parent user, the heuristic Data Vault classification is satellite-leaning; a modeling exercise would typically treat it as a satellite attached to the FND_USER hub through the USER_NAME column.

Key Information Stored

The table holds four documented columns, and the primary key is composed of the first three of them:

• USER_NAME (VARCHAR2, 320, mandatory) — The internal name of the user who owns the preference setting. This column carries the foreign-key relationship to FND_USER and anchors the satellite classification.
• MODULE_NAME (VARCHAR2, 30) — The application module that references the preference. It scopes the preference to a functional area, allowing the same user to hold distinct values for similarly named preferences across modules.
• PREFERENCE_NAME (VARCHAR2, 30) — The name of the preference being stored.
• PREFERENCE_VALUE (VARCHAR2, 240) — The actual value assigned to the preference for that user and module.

The composite primary key FND_USER_PREFERENCES_PK spans USER_NAME, MODULE_NAME, and PREFERENCE_NAME. The unique index FND_USER_PREFERENCES_U1 covers the same three columns and serves as the business-key candidate, enforcing that a given user may hold only one value per module-preference pair. The index resides in the APPS_TS_TX_IDX tablespace. Because the primary key is composite and entirely business-derived, no separate surrogate key column is documented; the natural identifiers function as the key.

Common Use Cases and Queries

Typical scenarios include troubleshooting a user's personalized behavior, auditing which preferences a module has persisted, migrating preferences between environments, and reporting on configuration drift across users or modules. The canonical retrieval pattern selects all preferences for a user, optionally filtered to a single module:

SELECT USER_NAME
     , MODULE_NAME
     , PREFERENCE_NAME
     , PREFERENCE_VALUE
FROM   APPLSYS.FND_USER_PREFERENCES
WHERE  USER_NAME = :p_user_name
AND    MODULE_NAME = :p_module_name;

A second common pattern targets a single preference across the user base, useful for impact analysis before a configuration change:

SELECT USER_NAME, PREFERENCE_VALUE
FROM   APPLSYS.FND_USER_PREFERENCES
WHERE  MODULE_NAME = :p_module_name
AND    PREFERENCE_NAME = :p_preference_name;

Reports frequently join the table to FND_USER on USER_NAME to resolve the owning user, and aggregation by MODULE_NAME and PREFERENCE_NAME is useful for identifying heavily used or sparsely populated settings. Because the unique index covers all key columns, the above predicates are fully index-supported.

Related Objects

The most significant relationships documented for this object are:

• APPLSYS.FND_USER — Referenced through USER_NAME, providing the owner of each preference and the hub linkage in a satellite model.
• APPS.FND_USER_PREFERENCES — The APPS synonym that provides the runtime access path used by concurrent programs and forms.
• FND_USER_PREFERENCES_PK — The primary-key constraint enforcing uniqueness across USER_NAME, MODULE_NAME, and PREFERENCE_NAME.
• FND_USER_PREFERENCES_U1 — The unique index supporting the business-key candidate and efficient lookups.

The table does not reference any other database object beyond the USER_NAME link to FND_USER, and its principal dependency remains the APPS synonym layer through which application code accesses the data.