Search Results igs_or_func_fltr




Overview
Explore in AI Chat

Overview

The IGS_OR_FUNC_FLTR table, owned by the IGS schema within the Oracle EBS Student System module, stores Organization Function Filter Details. Its role is to hold the configuration rules that determine which organizational units are permitted to perform specific business functions within an institution's academic and administrative hierarchy. In practical terms, the table acts as a control repository: each record ties a functional code to an attribute-based filter value, allowing the application to restrict or enable function execution according to the organizational context.

From a data modeling perspective, the ETRM metadata provides a heuristic Data Vault classification of standalone, meaning the table exhibits no discovered foreign key dependencies on other entities. In Data Vault terms this would suggest the object functions as an independent hub or reference table rather than a link or satellite, since it neither resolves a relationship between two business keys nor carries descriptive history dependent on another hub. This classification is a modeling suggestion derived from the mined FK structure and should be validated against the actual application's referential usage during implementations.

Key Information Stored

The table is documented with 11 columns. The most significant columns are:

  • FUNC_FLTR_ID — the surrogate primary key, enforced by the IGS_OR_FUNC_FLTR_PK constraint and additionally covered by the unique index IGS_OR_FUNC_FLTR_U1. This column is the sole documented business-key candidate and uniquely identifies each filter rule.
  • FUNC_CODE — the functional code identifying the business function to which the filter applies.
  • ATTR_TYPE — the attribute type used as the filtering criterion, defining how the filter is interpreted.
  • ATTR_VAL — the attribute value against which the organization or context is matched.
  • ATTR_VAL_DESC — a descriptive label for the attribute value, supporting readability in reporting and maintenance.
  • INST_ORG_VAL — the institution organization value that scopes the filter to a specific organizational unit.
  • CREATED_BY and CREATION_DATE — standard audit columns capturing who created the filter record and when.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — the standard EBS audit trail recording the most recent modification, timestamp, and user session.

The audit columns follow the conventional Oracle Applications "WHO" column pattern and are present in virtually every IGS transactional and setup table.

Common Use Cases and Queries

Typical scenarios include security and functional access configuration, organizational setup validation, and auditing of filter maintenance. A common query retrieves all filters defined for a given function:

  • SELECT func_fltr_id, attr_type, attr_val, attr_val_desc, inst_org_val FROM igs_or_func_fltr WHERE func_code = :p_func_code;
  • Joining organizational definitions to resolve the INST_ORG_VAL into a human-readable organization name for setup reports.
  • Audit queries filtering on LAST_UPDATE_DATE to identify recently modified filter rules.
  • Reporting queries that summarize which attribute types and values are most frequently configured across functions.

Because the table is classified as standalone, queries generally do not require multi-table joins to resolve the filter logic itself, simplifying extraction into reporting or reconciliation processes.

Related Objects

The documented FK metadata identifies no direct foreign key relationships, so related objects must be inferred from shared IGS naming conventions and functional context rather than from enforced constraints. Likely associated objects include the IGS organization definition tables (for example, organization and organization-unit entities that share the INST_ORG_VAL concept) and other IGS function or setup tables sharing the FUNC_CODE attribute. In a validated 12.2.2 environment, additional dependencies may be resolved through the system's referential definition or application views. Implementers should query USER_CONSTRAINTS and USER_DEPENDENCIES against IGS_OR_FUNC_FLTR to confirm the actual referencing objects, as the ETRM metadata explicitly reports no mined FK relationships for this table.