Search Results update_group

Overview

FND_SECURITY_GROUPS_API is a public PL/SQL API in the APPS schema that manages Oracle E-Business Suite security groups. Security groups provide row-level access control over application data; records in the EBS data model are assigned a security group, and users may only access records whose security group is included in their assigned responsibility's security group. This package therefore underpins the partitioning of data and menu structures between operating units, business groups, and other logical organizations that an enterprise defines in a multi-organization deployment. In Oracle EBS 12.1.1 and 12.2.2, the package is conventionally declared with AUTHID CURRENT_USER, and functions/procedures execute with the privileges of the caller.

The package provides a small, focused set of utility functions for validating the existence of a security group and transactional entry points for creating and updating them. It does not handle deletion; removal of security groups follows a separate administrative path. Because it centralizes validation and writes against the underlying base and translation-seeded tables, it is the supported programmatic route for managing security group definitions rather than direct DML.

Key Procedures and Functions

The documented interface exposes three boolean existence checks and two data manipulation entry points:

• ID_EXISTS — Returns TRUE when a security group with the supplied security group ID exists. Typically used prior to referencing a group by ID.
• KEY_EXISTS — Returns TRUE when a security group with the supplied internal key (the developer-facing identifier) exists. Useful for pre-insert uniqueness validation in custom loaders.
• NAME_EXISTS — Returns TRUE when a security group with the supplied user-facing name exists. Supports validation before create or update operations.
• CREATE_GROUP — Creates a new security group and returns the newly assigned Security_Group_Id. It accepts the internal key, user name, and description. An exception is raised if any error is encountered during insertion.
• UPDATE_GROUP — Updates values on an existing security group identified by its internal key; the caller may supply a new user name and description. The procedure returns no value.

All functions and procedures use the parameter names documented in the package specification; callers should pass values positionally or by named notation consistent with that specification.

Tables Accessed

The package operates against two APPS synonyms:

• FND_SECURITY_GROUPS — The base table storing the security group definition, including its key, user name, and description. It is read by the existence-check functions and written by CREATE_GROUP and UPDATE_GROUP.
• FND_SECURITY_GROUPS_S — The translation/seed table that supports the user-facing name and description. The API maintains this alongside the base table so that localized values remain consistent.

Only one other package in the EBS data model is documented as referencing FND_SECURITY_GROUPS_API, indicating that its use is intentionally narrow and should be reserved for security-group administration rather than general application logic.

Usage Notes

The package is typically invoked from the System Administrator responsibility while defining a security group through the Security Groups form, and from concurrent programs or setup loaders that seed security groups in a new installation or clone. Custom code should call the API rather than inserting directly into FND_SECURITY_GROUPS and FND_SECURITY_GROUPS_S, since CREATE_GROUP and UPDATE_GROUP enforce the necessary relationship between the base and translation rows and return the generated ID.

For the user search term "create_group," the relevant entry point is CREATE_GROUP; the existence functions KEY_EXISTS and NAME_EXISTS are conventionally called immediately beforehand to avoid duplicate-key errors. Commit or rollback remains the caller's responsibility, and CREATE_GROUP raises an exception on failure so that the surrounding transaction can be handled explicitly. Because updates are keyed by the internal security group key, the key itself is treated as the stable identifier while name and description may evolve.