Search Results fnd_login_resp_forms




Overview
Explore in AI Chat

Overview

The FND_LOGIN_RESP_FORMS table is a core audit and security object within the Oracle E-Business Suite Application Object Library (FND). It functions as a detailed audit trail, recording granular information about user sessions at the form level. Specifically, it logs which individual Oracle Forms a user navigates to and uses within a specific responsibility during a login session. This table is owned by the APPLSYS schema and is integral to the system's ability to track user activity for compliance, security monitoring, and usage analysis. Its data is a child of session information stored in FND_LOGINS and FND_LOGIN_RESPONSIBILITIES, creating a hierarchical audit trail from login to responsibility to form.

Key Information Stored

The table's structure is designed to link form usage to a specific user responsibility session. Its primary key is a composite of five columns, ensuring a unique record for each form instance launched within a session. The most critical columns include:

  • LOGIN_ID & LOGIN_RESP_ID: Foreign key columns linking to the FND_LOGIN_RESPONSIBILITIES table, identifying the specific responsibility session.
  • FORM_APPL_ID & FORM_ID: Foreign key columns linking to the FND_FORM table, identifying the exact Oracle Form that was accessed.
  • START_TIME: The timestamp when the form was initiated by the user. This is part of the primary key, allowing multiple instances of the same form within a single responsibility session to be recorded separately.

Additional columns typically found in such audit tables (though not explicitly listed in the provided metadata) would include fields like END_TIME to track form session duration and potentially other audit attributes.

Common Use Cases and Queries

The primary use case for FND_LOGIN_RESP_FORMS is generating detailed user activity reports for security audits and analyzing application form utilization. System administrators can query this table to investigate specific user actions, identify rarely used forms, or monitor access to sensitive forms. A typical analytical query joins to related tables to make the audit data readable:

SELECT fu.user_name,
r.responsibility_name,
f.form_name,
lrf.start_time
FROM apps.fnd_login_resp_forms lrf,
apps.fnd_login_responsibilities lr,
apps.fnd_logins fl,
apps.fnd_user fu,
apps.fnd_responsibility_tl r,
apps.fnd_form_tl f
WHERE lrf.login_id = lr.login_id
AND lrf.login_resp_id = lr.login_resp_id
AND lr.login_id = fl.login_id
AND fl.user_id = fu.user_id
AND lr.responsibility_id = r.responsibility_id
AND lrf.form_appl_id = f.application_id
AND lrf.form_id = f.form_id
AND fu.user_name = 'USER123'
AND trunc(lrf.start_time) = trunc(sysdate);

Related Objects

FND_LOGIN_RESP_FORMS sits within a hierarchy of login audit tables and has defined foreign key relationships, as per the metadata:

  • FND_LOGIN_RESPONSIBILITIES: The direct parent table. The foreign key on (LOGIN_ID, LOGIN_RESP_ID) enforces that every form usage record is tied to an active responsibility session.
  • FND_FORM: The reference table for form definitions. The foreign key on (FORM_APPL_ID, FORM_ID) ensures the recorded form is a valid application object.
  • FND_LOGINS: The grandparent table in the audit hierarchy, storing the initial sign-on event. It is accessed via the FND_LOGIN_RESPONSIBILITIES relationship.
  • FND_USER & FND_RESPONSIBILITY_TL: While not directly linked via foreign key, these tables are essential in queries to translate numeric IDs (USER_ID, RESPONSIBILITY_ID) into human-readable names for reporting.