Search Results hr_bpl_alert_recipient




Overview

APPS.HR_BPL_ALERT_RECIPIENT is a PL/SQL package body in the Oracle E-Business Suite Applications schema (APPS) that supports the Oracle Human Resources Business Process Library (BPL) framework, specifically the area concerned with identifying the appropriate recipients of HR alerts and notifications. Its central responsibility is to resolve, for a given business event, which person or assignment should receive a message — typically the employee themselves, or their supervisor — and to return the addressing and locale attributes needed to deliver it. The package therefore acts as a recipient-resolution utility for the HR alerting and workflow notification infrastructure, translating HR organizational and assignment data into concrete recipient identity elements: person names, electronic mail addresses, language codes, and scope membership.

The object carries a status of VALID in ETRM documentation for 12.1.1 and 12.2.2, and the API is classified as OTHER, reflecting that it is an internal supporting package rather than a formally published PL/SQL API. It is referenced by three other database objects and itself references no other package, making it a stable, low-level dependency used by higher-level notification and alerting components. Its position at the base of that dependency chain is consistent with its narrow, single-purpose design.

Key Procedures and Functions

The package body exposes 26 documented procedures and functions, which cluster into a small number of repeatable patterns applied across different recipient contexts.

No parameter lists are asserted here; only the documented purposes of these units are described. Callers should consult the package specification in the target instance for exact signatures.

Tables Accessed

The package reads from four core HR tables, accessed through APPS synonyms. PER_ALL_PEOPLE_F supplies the person-level attributes used to derive names, email addresses, language preferences, and supervisor relationships. PER_ALL_ASSIGNMENTS_F supplies assignment-level context, including the assignment-to-person mapping and the relationship used to identify a supervisor for assignment-scoped resolution. PER_ASSIGNMENT_STATUS_TYPES is used to evaluate assignment status, which underpins the in-scope checks and ensures notifications are directed only to recipients whose assignments are in an appropriate status. HR_ORGANIZATION_INFORMATION supports the organizational scope determination, providing the business group and organization-level information needed by GET_BG_LNG and the scope validation routines. The package appears to be read-only with respect to these tables, consistent with a resolution utility that observes HR data rather than maintaining it.

Usage Notes

HR_BPL_ALERT_RECIPIENT is typically invoked indirectly rather than called directly by end users. It is most commonly exercised through HR self-service alerting and notification flows, where a business event requires the system to determine an employee or manager recipient and retrieve the appropriate delivery attributes. Because it is referenced by three other database objects and references none, it functions as a leaf dependency in the notification stack, and the documented procedures are therefore likely to be invoked from workflow notification activities, concurrent programs that dispatch HR alerts, and custom extensions that need to reuse Oracle's standard recipient resolution logic rather than query PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F directly. Developers integrating with the package should treat the get-prefixed functions as read-only lookups and the check-prefixed functions as boolean-style scope tests, and should be aware that name, email, and language resolution differ across the person, assignment, and primary-assignment variants, so the correct variant must be selected to match the alert's targeting context. As an unsupported internal package classified as OTHER, it should be used with caution in customizations, since its behavior is governed by the HR BPL alerting framework rather than a published API commitment.