Search Results ame_approval_groups_pk

Overview

HR.AME_APPROVAL_GROUPS is the Oracle E-Business Suite Approvals Management Engine (AME) table that defines named groups of approvers. AME uses these groups as reusable approver containers that can be referenced by approval rules, enabling routing decisions to target a collective set of approvers rather than individual users. Although the table resides in the HR schema, its FND Design Data designation PER.AME_APPROVAL_GROUPS confirms it is registered as an application-owned object within the Oracle EBS data dictionary. The object holds a VALID status in both 12.1.1 and 12.2.2, and its physical storage resides in the APPS_TS_TX_DATA tablespace with an index in APPS_TS_TX_IDX, reflecting its transactional nature.

From a data modeling perspective, the mined relationship data classifies this object as standalone. In Data Vault terms, it functions most naturally as a satellite attached to an approver-group business key, since it stores descriptive and behavioral attributes (name, query text, static flag, effective dates) rather than participating in a many-to-many link structure. The absence of documented foreign keys referencing other core AME entities reinforces this interpretation.

Key Information Stored

The table comprises 15 documented columns, of which the following are the most operationally significant:

• APPROVAL_GROUP_ID — Numeric surrogate primary key uniquely identifying each approver group.
• NAME — The user-facing approver group name, limited to 50 characters.
• QUERY_STRING — A SQL statement used to resolve the members of a dynamic approver group at runtime; the 4000-character limit accommodates reasonably complex member-selection logic.
• IS_STATIC — A flag indicating whether the group's membership is fixed (static) or resolved dynamically through QUERY_STRING.
• DESCRIPTION — Free-text explanation of the group's purpose.
• START_DATE / END_DATE — Activation and inactivation dates governing the row's effective lifespan.
• OBJECT_VERSION_NUMBER — System-maintained version counter incremented on each update, supporting optimistic locking.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who audit columns.

The unique index AME_APPROVAL_GROUPS_PK spans APPROVAL_GROUP_ID, START_DATE, END_DATE, and ZD_EDITION_NAME, indicating that the surrogate key is effectively date-effective and edition-aware rather than the ID column alone. SECURITY_GROUP_ID is documented as not used, and ZD_EDITION_NAME supports the editioning mechanism introduced in later releases.

Common Use Cases and Queries

Typical usage centers on inspecting group definitions, validating dynamic SQL, and auditing membership behavior. A representative query lists active groups by name:

• SELECT APPROVAL_GROUP_ID, NAME, IS_STATIC, DESCRIPTION FROM HR.AME_APPROVAL_GROUPS WHERE SYSDATE BETWEEN START_DATE AND NVL(END_DATE, SYSDATE);
• Retrieve the SQL behind dynamic groups: SELECT NAME, QUERY_STRING FROM HR.AME_APPROVAL_GROUPS WHERE IS_STATIC = 'N';
• Join to FND_SECURITY_GROUPS on SECURITY_GROUP_ID where security-group segmentation is employed.

Reporting scenarios include auditing which approval rules rely on static versus dynamic groups, tracing approver routing during month-end close, and reviewing QUERY_STRING values during upgrade or performance tuning, since inefficient dynamic queries can slow approval processing.

Related Objects

The metadata documents a single foreign-key relationship from SECURITY_GROUP_ID to FND_SECURITY_GROUPS. By AME design, downstream dependencies include the AME approval-rule and action tables, which consume APPROVAL_GROUP_ID when a rule action references an approver group, and AME runtime resolution logic that interprets QUERY_STRING. The companion editioning view HR.AME_APPROVAL_GROUPS# exposes the editioned data. Related functional objects include AME approval-list and attribute tables, plus the standard Who reference to FND_USER through the audit columns. These relationships make HR.AME_APPROVAL_GROUPS a central reference point for understanding how AME assembles approver populations within Oracle EBS.