Search Results fnd_notifications_v




Overview
Explore in AI Chat

Overview

FND_NOTIFICATIONS_V is a read-only database view owned by the APPS schema and defined over the FND_NOTIFICATIONS base table. In Oracle E-Business Suite 12.1.1 and 12.2.2, the object is classified under the PO (Purchasing) product module and carries the designation "Retrofitted," indicating that it was introduced or reconstructed during an upgrade or point-release migration rather than designed as an original application object. The view exposes the full set of notification attributes used by the Oracle Workflow notification and notification-mailer infrastructure, presenting one row per workflow notification generated by an application.

Functionally, the view serves as a reporting and integration surface for notification data. Because notifications are associated with employees, message names, document references, and effective date ranges, the view is commonly used to audit notification traffic, drive custom dashboards, and feed downstream interfaces that require visibility into pending, open, or closed workflow notifications. The status remains VALID in the documented environments.

Underlying Base Objects

The documented metadata states that FND_NOTIFICATIONS_V is defined over the base object FND_NOTIFICATIONS, accessed through a synonym in the APPS schema. The view text is a straightforward projection: it selects the column list directly from FND_NOTIFICATIONS with no joins, unions, filtering, or aggregation. Consequently, the view inherits the row cardinality, constraints, indexes, and triggers of the base table without modification. Any insert, update, or delete performed through the view would be subject to the base table's constraints, though in practice the object is used for query access only.

Key Columns

  • NOTIFICATION_ID — Primary identifier for each workflow notification; the join key to other Workflow notification views.
  • APPLICATION_ID — Identifies the application that generated the notification.
  • EMPLOYEE_ID — The recipient or associated employee; joins to HR employee tables.
  • MESSAGE_NAME — Name of the Workflow message definition used to render the notification.
  • STATUS — Notification state (for example open, closed, or canceled).
  • START_EFFECTIVE_DATE / END_EFFECTIVE_DATE — The effective window for the notification. The END_EFFECTIVE_DATE column defines when the notification ceases to be active, making it the standard predicate for isolating current versus expired notifications.
  • FROM_ID — The originating role or user of the notification.
  • DOC_CREATION_DATE, DOC_TYPE, DOC_NUMBER, OBJECT_ID — Document context allowing the notification to be traced back to the business document that triggered it.
  • AMOUNT, CURRENCY — Monetary values carried by purchasing-related notifications.
  • PRIORITY — Delivery priority assigned to the notification.
  • DATE1–DATE4, ATTRIBUTE1–ATTRIBUTE32, NOTE — Descriptive flexfield and free-format columns available for application-specific enrichment.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit columns.

Common Use Cases and Queries

A frequent requirement is identifying notifications that are still within their effective period or that have already expired. The END_EFFECTIVE_DATE column is the determinant for this test:

SELECT notification_id, employee_id, message_name, status,
       start_effective_date, end_effective_date
  FROM apps.fnd_notifications_v
 WHERE status = 'OPEN'
   AND (end_effective_date IS NULL OR end_effective_date > SYSDATE);

A second common pattern reconciles notifications against their source purchasing documents by joining DOC_NUMBER and OBJECT_ID to the relevant PO tables, often filtered by DOC_CREATION_DATE to constrain the reporting window. A third pattern aggregates notification volume by application and message name for workload analysis. Because the view performs no filtering, it is advisable to apply selective predicates on STATUS, APPLICATION_ID, or the effective date columns, and to confirm that the base table's indexes support the intended access path.