Search Results gms_notifications_u1

Overview

GMS.GMS_NOTIFICATIONS is a transactional configuration table in the Oracle E-Business Suite Grants Management (GMS) module. Its documented purpose is to store the USER_ID values that receive notifications associated with different award event types. In practical terms, the table acts as a subscription or recipient list: for a given award and a given event type, one or more users are registered to receive the corresponding notification. This makes it a supporting object for the Grants Management notification engine rather than a master or transactional award record in its own right.

The table resides in the GMS schema, is owned by GMS, carries FND Design Data under the same name, and has a documented status of VALID in both Oracle EBS 12.1.1 and 12.2.2. It is stored in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. Because the table contains only three columns — all of which participate in the primary unique key — it behaves as a narrow, high-read association table.

Under the heuristic Data Vault classification mined from its foreign key structure, GMS_NOTIFICATIONS is satellite-leaning. This classifies it as a descriptive or associative structure attached to a parent hub, in this case the award, rather than as an independent hub or a pure many-to-many link. The modeling suggestion is to treat it as a dependent satellite keyed to the award and event type, capturing which users are configured as notification recipients. This classification is a heuristic derived from the FK structure and should be validated against the actual Grants Management notification configuration before being used as a data warehouse design decision.

Key Information Stored

GMS_NOTIFICATIONS is documented with exactly three columns, and no surrogate system-generated primary key is present in the ETRM metadata. The uniqueness of a row is instead enforced entirely by the composite business key, which is a notable design characteristic for this object.

• AWARD_ID (NUMBER(15), mandatory) — the award identifier. This column anchors the notification configuration to a specific award and is the FK relationship to IGF_AW_AWARD_ALL.
• EVENT_TYPE (VARCHAR2(30), mandatory) — the award event type for which the notification is sent. This is the discriminator that distinguishes which notification stream a given user is subscribed to for the award.
• USER_ID (NUMBER(15), mandatory) — the user identifier, with an FK relationship to FND_USER, identifying the recipient of the notification.
• Business-key candidate (unique index GMS_NOTIFICATIONS_U1) — the unique index GMS_NOTIFICATIONS_U1 is defined as NORMAL and UNIQUE on the column combination (AWARD_ID, EVENT_TYPE, USER_ID), stored in the APPS_TS_TX_IDX tablespace. This composite key is the sole documented uniqueness constraint and therefore serves as the de facto primary key.

Because all three columns participate in GMS_NOTIFICATIONS_U1, there are no non-key attribute columns. The table therefore stores no descriptive or historical data beyond the association itself — each row simply records that a particular user is configured to receive notifications for one event type on one award.

Common Use Cases and Queries

The primary use case is determining who is configured to receive notification for a given award event, and conversely which awards and event types a particular user is subscribed to. Grants administrators use the table to review and audit notification recipient setup before award events are processed, and support teams query it when a user reports not having received an expected notification.

A baseline query follows the documented Query Text and returns the full configuration for an award:

• SELECT AWARD_ID, EVENT_TYPE, USER_ID FROM GMS.GMS_NOTIFICATIONS WHERE AWARD_ID = :award_id;
• SELECT EVENT_TYPE, USER_ID FROM GMS.GMS_NOTIFICATIONS WHERE AWARD_ID = :award_id ORDER BY EVENT_TYPE, USER_ID;
• SELECT AWARD_ID, EVENT_TYPE FROM GMS.GMS_NOTIFICATIONS WHERE USER_ID = :user_id; — lists all subscriptions for one recipient, useful when deactivating or troubleshooting a user.
• SELECT EVENT_TYPE, COUNT(*) FROM GMS.GMS_NOTIFICATIONS WHERE AWARD_ID = :award_id GROUP BY EVENT_TYPE; — summarizes recipient counts per event type.

For reporting, joining to award and user sources enriches the numeric identifiers with meaningful descriptions. A common pattern is to join AWARD_ID to IGF_AW_AWARD_ALL for award number and name, and USER_ID to FND_USER for the user name, so administrators can review recipients by name rather than by internal ID. Duplicate-recipient reports across event types can be produced by grouping on AWARD_ID and USER_ID. Because the table is small and key-only, queries against GMS_NOTIFICATIONS_U1 are highly selective and inexpensive.

Related Objects

The ETRM metadata documents the following relationships as the most significant dependencies for this object:

• IGF_AW_AWARD_ALL — referenced through GMS_NOTIFICATIONS.AWARD_ID → IGF_AW_AWARD_ALL. This is the award source table supplying award context for every notification configuration row.
• FND_USER — referenced through GMS_NOTIFICATIONS.USER_ID → FND_USER. This supplies the recipient identity for each subscription.
• GMS_NOTIFICATIONS# — a dependent object referenced by GMS_NOTIFICATIONS, the standard Oracle EBS shadow/key-preserving structure associated with the table.

The GMS schema itself is listed as the referencing owner. The table is documented as not referencing any other database object beyond the two foreign keys above, which keeps its dependency footprint narrow and focused on the award and user dimensions. Because it is a Grants Management notification configuration object, related Grants Management notification and award event processing logic should be reviewed alongside it when tracing end-to-end notification behavior; however, the ETRM metadata provided documents only the award, user, and shadow-object relationships, and those should be treated as the authoritative dependency list for this object.