Search Results reject_enroll_del_pend_user




Overview
Explore in AI Chat

Overview

JTF_UM_ENROLLMENT_CREDENTIALS is an APPS-owned PL/SQL package within the Oracle E-Business Suite User Management (UM) framework. Its principal business function is to administer the provisioning and de-provisioning of enrollment credentials for users who register through the self-service or delegated enrollment flows. In practical terms, the package binds together three logically distinct operations: creating a user's enrollment registration, granting the responsibilities and roles associated with that enrollment, and, where an approval workflow is configured, either routing the request for approval or rejecting and cleaning up pending users. Because it manipulates responsibility assignments against FND_USER, it is a security-sensitive API and is classified under ETRM as OTHER, indicating it is not published as a general-purpose open interface but is consumed internally by the enrollment subsystem.

The package is documented in both Oracle EBS 12.1.1 and 12.2.2. The header comment visible in the source ($Header: JTFUMECS.pls 120.2 2005/10/29) confirms a long-standing, stable code line that has been carried forward across releases with minimal structural change.

Key Procedures and Functions

The ETRM metadata documents five named entry points (with two of the responsibility procedures overloaded, giving seven documented callable units):

  • ASSIGN_ENROLLMENT_CREDENTIALS — Assigns the credentials associated with a subscription to a named user, correlating the user name, user identifier, and subscription identifier.
  • ASSIGN_RESPONSIBILITY — Overloaded to accept either a numeric responsibility identifier or a responsibility key, together with the application identifier, to grant a responsibility to a user.
  • REVOKE_RESPONSIBILITY — Overloaded in the same manner as the assign procedure, removing a previously granted responsibility from a user based on identifier or key.
  • REJECT_ENROLL_DEL_PEND_USER — Rejects an enrollment and deletes the associated pending user record, identified by user name.
  • ASSIGN_USER_ENROLLMENT — The orchestrating procedure. Its documented internal logic creates the user enrollment; if approval is required it assigns enrollment credentials, otherwise it launches the workflow process. It accepts user, user type, enrollment, delegate flag, and approval identifiers, and returns an enrollment registration identifier.

No parameter-level detail beyond that documented in the package specification should be assumed.

Tables Accessed

The package operates across the core User Management data model:

  • FND_USER — The base user repository; responsibility grants are recorded against the user record, and pending users are removed here on rejection.
  • JTF_UM_APPROVALS_B — Stores approval metadata; the approval identifier passed to ASSIGN_USER_ENROLLMENT determines whether a workflow is launched or credentials are granted immediately.
  • JTF_UM_SUBSCRIPTION_REG — Holds subscription registration records created during enrollment.
  • JTF_UM_SUBSCRIPTION_RESP — Maps subscriptions to responsibilities, driving the grants performed by ASSIGN_ENROLLMENT_CREDENTIALS.
  • JTF_UM_SUBSCRIPTION_ROLE — Maps subscriptions to roles, complementing the responsibility grants.
  • JTF_UM_USERTYPE_REG — Associates user types with registration rules, informing which credentials are provisioned.

Usage Notes

JTF_UM_ENROLLMENT_CREDENTIALS is normally invoked indirectly. The primary consumers are the User Management enrollment pages and the approval workflow that governs self-service registration; the ETRM metadata records that the package is referenced by one other package, consistent with it sitting beneath the enrollment business logic layer rather than at the top. It should not be called directly from custom code without first understanding the approval path, because ASSIGN_USER_ENROLLMENT branches between immediate credential assignment and deferred workflow-based approval. Custom integrations that must provision responsibilities outside the standard enrollment flow should prefer the supported FND_USER_PKG or the documented UM enrollment APIs rather than calling these procedures directly, to avoid bypassing approval controls and audit expectations.