Results for “fnd_security_groups_u1”

12 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPLSYS.FND_SECURITY_GROUPS is an Oracle E-Business Suite seed table that stores the definition of security groups. Security groups are the partitioning construct used in a Service Bureau (multi-tenant) architecture, allowing a single EBS instance and a shared APPLSYS schema to host the data of multiple logically isolated business entities. Each security group acts as a tag applied to application data so that concurrent programs, reports, and forms restrict access to records belonging to the group under which the session runs.

The object is owned by APPLSYS and is flagged VALID in the ETRM 12.2.2 documentation. It carries FND design data designation FND.FND_SECURITY_GROUPS, confirming that it is an Applications Object Library (AOL) seed object, and it resides in the APPS_TS_SEED tablespace, consistent with its role as reference data rather than transactional data. The documented physical schema contains eight columns. Both unique indexes, FND_SECURITY_GROUPS_U1 and FND_SECURITY_GROUPS_U2, include the ZD_EDITION_NAME column, indicating that the table participates in the Edition-Based Redefinition (EBR) model introduced for online patching in EBS 12.2.

From a heuristic Data Vault modeling perspective, the mined relationship structure classifies this table as hub-leaning. It is referenced by an exceptionally large number of foreign keys across nearly every product family, while it itself references no database object. This pattern — a narrow, low-cardinality reference table anchoring many dependent tables — is characteristic of a hub entity whose business key is SECURITY_GROUP_KEY.

Key Information Stored

The table's documented column set is compact and can be divided into the surrogate primary key, the business key, and standard audit columns.

  • SECURITY_GROUP_ID (NUMBER, 15) — The surrogate identifier and primary key of the table, defined by constraint FND_SECURITY_GROUPS_PK. It is also the leading column of unique index FND_SECURITY_GROUPS_U1. This is the value propagated to the hundreds of child tables that carry a SECURITY_GROUP_ID foreign key.
  • SECURITY_GROUP_KEY (VARCHAR2, 30) — The developer key, a short human-readable name for the security group. It is the leading column of unique index FND_SECURITY_GROUPS_U2, making it the primary business-key candidate.
  • CREATED_BY (NUMBER, 15) — Standard Who column identifying the user who created the security group definition.
  • CREATION_DATE (DATE) — Standard Who column recording when the row was inserted.
  • LAST_UPDATED_BY (NUMBER, 15) — Standard Who column identifying the user who last modified the row.
  • LAST_UPDATE_DATE (DATE) — Standard Who column recording the timestamp of the last modification.
  • LAST_UPDATE_LOGIN (NUMBER, 15) — Standard Who column capturing the login/session identifier associated with the last update.
  • ZD_EDITION_NAME (VARCHAR2, 30) — The edition discriminator introduced by EBR. It is included in both unique indexes, meaning uniqueness of the security group ID and key is enforced per edition.

Common Use Cases and Queries

The principal operational use case is data partitioning in a Service Bureau deployment. When a user signs on, the security group associated with the responsibility or session determines which rows are visible. Reporting and reconciliation queries therefore join FND_SECURITY_GROUPS to child tables on SECURITY_GROUP_ID to resolve the human-readable group behind a set of tenant rows, and to audit which objects have been tagged.

A basic lookup of all defined security groups uses the supplied query text:

SELECT SECURITY_GROUP_ID, SECURITY_GROUP_KEY, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, ZD_EDITION_NAME FROM APPLSYS.FND_SECURITY_GROUPS;

To attribute transactional data to a named group, join on the foreign key; for example, listing concurrent requests by security group:

SELECT r.request_id, g.security_group_key FROM fnd_concurrent_requests r JOIN fnd_security_groups g ON g.security_group_id = r.security_group_id;

A frequent diagnostic exercise is identifying how widely a given group is referenced, since the table sits at the centre of a very large reference web. Counting rows in high-volume dependents such as WF_ITEMS, WF_NOTIFICATIONS, or CS_INCIDENTS_ALL_B — each of which carries a SECURITY_GROUP_ID — helps administrators understand the data footprint and assess the impact of retiring or merging a group. Because ZD_EDITION_NAME participates in both unique indexes, any query run in an EBR-enabled 12.2 environment should be edition-aware, and direct DML against this seed table should be avoided in favour of supported AOL setup paths.

Related Objects

FND_SECURITY_GROUPS does not reference any database object, but it is referenced through SECURITY_GROUP_ID foreign keys by an extensive set of tables spanning Oracle Workflow, CRM, Service, Contracts, Advanced Pricing, and Financials. The most significant dependents include:

  • FND_CONCURRENT_REQUESTS.SECURITY_GROUP_ID — associates submitted concurrent requests with the security group under which they were executed, central to partition-aware concurrent processing.
  • FND_CONCURRENT_PROGRAMS.SECURITY_GROUP_ID — restricts concurrent program definitions to a security group.
  • WF_ITEMS.SECURITY_GROUP_ID and WF_NOTIFICATIONS.SECURITY_GROUP_ID — partition Workflow runtime items and notifications.
  • CS_INCIDENTS_ALL_B.SECURITY_GROUP_ID and CS_INCIDENT_TYPES_B.SECURITY_GROUP_ID — partition Service (TeleService) incident data.
  • JTF_RS_SALESREPS.SECURITY_GROUP_ID and JTF_RS_RESOURCE_EXTNS.SECURITY_GROUP_ID — tie CRM sales representatives and resource records to a group.
  • OKC_K_HEADERS_B.SECURITY_GROUP_ID — partitions Contracts (OKC) header data.
  • AS_SALES_LEADS.SECURITY_GROUP_ID — partitions Sales Foundation lead records.
  • GL_DEFAS_RESP_ASSIGN.SECURITY_GROUP_ID — links General Ledger responsibility assignments to a security group.
  • FND_LOOKUP_TYPES.SECURITY_GROUP_ID — allows lookup types themselves to be secured per group.
  • FND_LOG_TRANSACTION_CONTEXT.SECURITY_GROUP_ID — records the security group in the common logging transaction context.

In addition, the ETRM dependency listing notes an internal reference from APPLSYS.FND_SECURITY_GROUPS#, the EBR editioning view (or shadow object) associated with the base table in the 12.2 schema.