Search Results crm_domain




Overview

JTF_AUTH_BULKLOAD_PKG is a public PL/SQL package in the APPS schema that provides a programmatic interface for bulk role assignment within the Oracle E-Business Suite CRM domain. Its central business purpose is to grant an existing role to an existing user without requiring the caller to navigate the standard administrative user interface. The package establishes the authorization mapping between a user principal and a role principal inside the CRM_DOMAIN authorization domain, which is the repository consumed by CRM applications and any component that relies on the JTF authorization framework for access control decisions.

The package is declared with AUTHID CURRENT_USER, meaning its unqualified references resolve against the privileges of the invoking schema rather than the definer. It carries an API classification of OTHER in the ETRM metadata for 12.2.2, is owned by APPS, and is referenced by seven other packages, indicating that it operates as a foundational utility invoked by higher-level bulk provisioning, migration, and integration routines rather than as an end-user component. The header revision (120.1) is unchanged across the 12.1.1 and 12.2.2 releases relevant to this discussion.

Key Procedures and Functions

The ETRM metadata documents a single named procedure, ASSIGN_ROLE, which exists as four overloaded signatures. All overloads share the same fundamental semantic: they assign an existing role to an existing user in the CRM_DOMAIN.

  • ASSIGN_ROLE (user, role) — the base overload, which creates the principal-to-role mapping using only the user name and role name. Both the user name and the role name are treated case-insensitively; lower-case input is converted to upper case.
  • ASSIGN_ROLE (user, role, owner table name, owner table key) — extends the mapping with source-table attribution. The owner table name must exist in FND_LOOKUPS and is also case-insensitive, while the owner table key identifies the specific source row for which the assignment is recorded.
  • ASSIGN_ROLE (user, role, application id) — scopes the assignment to a specific application identifier.
  • ASSIGN_ROLE (user, role, owner table name, owner table key, application id) — the most complete overload, combining source-table attribution with an explicit application scope.

The overloaded design allows callers to record assignments at the level of detail appropriate to their integration, ranging from a simple user-to-role grant to a fully attributed mapping carrying both originating source metadata and application context.

Tables Accessed

The package operates against the JTF authorization data model and its supporting reference tables, all accessed through APPS synonyms.

  • FND_USER — validated to confirm the target user exists and to resolve the user identifier; user names are case-normalized on input.
  • JTF_AUTH_PRINCIPALS_B — the principal repository holding both user and role principals participating in the assignment.
  • JTF_AUTH_DOMAINS_B — the domain definition table used to anchor the mapping in CRM_DOMAIN.
  • JTF_AUTH_PRINCIPAL_MAPS — the core mapping table into which the user-to-role association is written.
  • JTF_AUTH_MAPS_SOURCES — stores source-table attribution when owner table name and key are supplied.
  • JTF_AUTH_S1 — sequence used to generate identifiers for newly created mapping rows.
  • DUAL — used for scalar expression evaluation and existence checks.

Usage Notes

JTF_AUTH_BULKLOAD_PKG is designed for set-based or scripted provisioning, not interactive use. It is typically invoked from custom PL/SQL loaders, migration scripts, and integration programs that must assign CRM roles to large numbers of users, and it may be reached from concurrent-program wrappers or from other packages — the ETRM metadata records seven dependent packages. Because it is a public APPS package, custom code should call the overload matching the required attribution granularity and pass user and role names in a consistent case to avoid redundant conversion. Callers should ensure the user and role already exist, since the procedure assigns existing roles and does not create principals. Testing should be performed in a non-production environment, and the assignment results should be verified in the JTF authorization tables before promotion.