Search Results pv_party_notifications_u2




Overview

PV.PV_PARTY_NOTIFICATIONS is a transactional table in the Oracle E-Business Suite Partner and Vendor (PV) product family. It stores the status of party notifications dispatched through the Oracle Workflow notification framework. Each row represents a discrete notification event targeted at a party, capturing the notification type, the associated lead assignment, the recipient user, and the workflow item that carried the message. The table therefore acts as the persistence and audit layer that links business events in the lead assignment process to their Workflow-generated messages and the responses those messages elicit.

Following heuristic Data Vault modeling conventions derived from its foreign key structure, this object most closely resembles a link table. It does not hold a durable business entity of its own; rather, it associates independent hubs — lead assignments, users, and resources — while carrying descriptive attributes about the notification transaction itself. Consumers should treat this classification as a modeling suggestion, not as a documented Oracle construct.

Key Information Stored

The surrogate primary key is PARTY_NOTIFICATION_ID, enforced by the unique index PV_PARTY_NOTIFICATIONS_U1. Business-key candidates are defined by the composite unique index PV_PARTY_NOTIFICATIONS_U2 across (LEAD_ASSIGNMENT_ID, NOTIFICATION_TYPE, USER_ID), which guarantees that a given user receives at most one notification of a given type per lead assignment.

The most significant columns include:

Common Use Cases and Queries

Typical usage centers on reporting notification volumes, auditing recipient responses, and diagnosing Workflow delivery. A common pattern joins the table to its parents to resolve context:

SELECT p.PARTY_NOTIFICATION_ID, p.NOTIFICATION_TYPE, p.RESPONSE_DATE, u.USER_NAME
FROM PV.PV_PARTY_NOTIFICATIONS p, FND_USER u
WHERE p.USER_ID = u.USER_ID
AND p.LEAD_ASSIGNMENT_ID = :lead_assignment_id;

A second frequent query retrieves outstanding notifications that have no recorded response, filtering on RESOURCE_RESPONSE IS NULL and ordering by RESPONSE_DATE. A third pattern joins on WF_ITEM_TYPE and WF_ITEM_KEY to correlate records with WF_ITEM tables for troubleshooting stalled Workflow items. Because the table is indexed on USER_ID, USER_NAME, RESOURCE_ID, and the Workflow pair, these access paths are efficient. Reporting use cases include lead response rate analysis, notification turnaround time, and partitioning-aware extracts that include SECURITY_GROUP_ID.

Related Objects

  • PV_LEAD_ASSIGNMENTS — joined via LEAD_ASSIGNMENT_ID; the parent lead assignment.
  • FND_USER — joined via USER_ID and USER_NAME; the notification recipient.
  • JTF_RS_RESOURCE_EXTNS — joined via RESOURCE_ID; the associated resource.
  • FND_SECURITY_GROUPS — joined via SECURITY_GROUP_ID; tenant security partitioning.
  • Oracle Workflow runtime tables (referenced by WF_ITEM_TYPE / WF_ITEM_KEY) — the notification delivery mechanism.

The table is normally accessed through the PV lead management application logic rather than directly, and any direct DML should respect the unique constraints enforced by PV_PARTY_NOTIFICATIONS_U1 and PV_PARTY_NOTIFICATIONS_U2.