Search Results waitlist_alwd




Overview
Explore in AI Chat

Overview

The IGS_EN_INST_WLST_OPT_ALL table is a core configuration entity within the Oracle E-Business Suite Student System (IGS) module. It stores institutional-level waitlist options that are scoped to specific calendar instances, allowing an institution to define whether waitlisting is permitted for a given academic calendar type and to control how waitlist behavior is applied across enrollment processing.

From a Data Vault modeling perspective, the heuristic classification derived from the foreign-key structure is standalone. This suggests the table can be treated as an independent reference or configuration entity rather than as a hub, link, or satellite participating in a broader integration network. It functions as a setup table that governs downstream enrollment and registration logic.

Key Information Stored

The table contains 11 documented columns in the 12.1.1 physical schema. The most significant are:

  • INST_WAITLIST_ID — The surrogate primary key of the table, defined by the IGS_EN_INST_WLST_OPT_ALL_PK constraint and also enforced by the unique index IGS_EN_INST_WLST_OPT_ALL_U1.
  • CAL_TYPE — The calendar type to which the waitlist option applies. This is the second business-key candidate, enforced by the unique index IGS_EN_INST_WLST_OPT_ALL_U2, ensuring a single option row per calendar type at the institutional level.
  • SEQUENCE_NUMBER — Controls ordering or precedence of the waitlist option record, useful when multiple configurations must be evaluated in a deterministic sequence.
  • WAITLIST_ALWD — A flag indicating whether waitlisting is allowed for the associated calendar instance.
  • SMLNES_WAITLIST_ALWD — A flag indicating whether simultaneous waitlisting is permitted, allowing a student to hold multiple waitlist positions concurrently.
  • ORG_ID — The operating unit or organization identifier, supporting multi-org access control and partitioning of institutional waitlist configuration.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — The standard EBS audit columns that record who created and last modified the row and when.

The distinction between INST_WAITLIST_ID and CAL_TYPE is important: the former is the technical surrogate key used for referential integrity, while the latter is the business key that users recognize and configure.

Common Use Cases and Queries

Typical scenarios include verifying whether waitlisting is enabled for a specific calendar type, auditing institutional waitlist configuration across operating units, and driving enrollment validation logic. A representative query is:

  • SELECT inst_waitlist_id, cal_type, waitlist_alwd, smlnes_waitlist_alwd FROM igs_en_inst_wlst_opt_all WHERE cal_type = :cal_type AND org_id = :org_id; — retrieves the effective waitlist options for a calendar type within an operating unit.
  • SELECT cal_type, waitlist_alwd FROM igs_en_inst_wlst_opt_all ORDER BY sequence_number; — reports configured options in precedence order.
  • SELECT * FROM igs_en_inst_wlst_opt_all WHERE waitlist_alwd = 'Y'; — identifies all calendar types where waitlisting is permitted.

Reporting use cases include waitlist configuration audits, setup verification before term activation, and troubleshooting enrollment issues where a student cannot be waitlisted due to a disabled option.

Related Objects

Although the documented relationship classification is standalone, the table logically interacts with several Student System objects:

  • IGS_EN_INST_WLST_OPT_ALL itself is referenced by configuration validation logic through CAL_TYPE matching against calendar type definitions maintained in the IGS calendar setup tables.
  • Calendar and term setup tables in the IGS schema that define CAL_TYPE values consumed by this table.
  • Enrollment and registration processing entities that read WAITLIST_ALWD and SMLNES_WAITLIST_ALWD to determine waitlist eligibility.
  • Student waitlist record tables that store individual waitlist positions governed by the institutional options defined here.
  • ORG_ID-based multi-org views and security profiles that filter access to this configuration.

Because the mined relationship data indicates a standalone classification, no formal foreign-key dependencies are documented; integration is achieved through CAL_TYPE and ORG_ID value matching rather than enforced constraints.