Search Results bis_levels_customizations

Overview

BIS_LEVELS_CUSTOMIZATIONS is a configuration table within the Oracle EBS Applications BIS product family. It records which users, responsibilities, applications, organizations, sites, pages, and functions have been selectively enabled or disabled against a defined BIS level. The BIS_LEVELS_CUSTOMIZATIONS.LEVEL_ID foreign key ties each customization row to a parent level defined in MSD_LEVELS, making this object a per-level tailoring mechanism that overrides default behavior for specific runtime contexts.

In Oracle EBS 12.1.1 and 12.2.2 the table is documented with 15 columns, owned by the BIS schema. The 12.1.1 ETRM entry explicitly states that this object is "Not implemented in this database," meaning the physical structure exists in the data dictionary metadata but is not populated in that release's seeded instance. This is common for internal or product-specific tables that activate only under certain licensing or configuration scenarios.

From a heuristic Data Vault modeling perspective, this table is classified as standalone, based on the mined foreign key structure. It has no child tables referencing it, so it behaves as a terminal satellite-like object rather than a hub or link in an integration model. Its single documented FK relationship is a point of reuse for drill-back reporting rather than a hub anchor.

Key Information Stored

The primary surrogate key is the ID column, which uniquely identifies each customization record. The business-relevant anchor is LEVEL_ID, the foreign key to MSD_LEVELS, which establishes the level to which the customization applies.

The ENABLED column stores the flag that determines whether the customization is active — effectively the override value applied for the matched context. USER_ID and RESPONSIBILITY_ID identify the runtime user and responsibility scope, while APPLICATION_ID, ORG_ID, and SITE_ID narrow the customization further to an application, operating unit, or site.

PAGE_ID and FUNCTION_ID enable function-level or page-level tailoring, which is significant for BIS pages and the underlying function security model. The audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN follow standard EBS WHO-column conventions and support change tracking and audit reporting. No unique index columns beyond the surrogate ID are documented in the ETRM metadata.

Common Use Cases and Queries

Typical usage involves reporting which levels have customizations applied, auditing who enabled or disabled a given context, and diagnosing why a page or function behaves differently for a specific user or responsibility. A representative join against the parent level table:

• SELECT blc.ID, blc.LEVEL_ID, ml.LEVEL_NAME, blc.ENABLED, blc.USER_ID, blc.RESPONSIBILITY_ID FROM BIS_LEVELS_CUSTOMIZATIONS blc JOIN MSD_LEVELS ml ON blc.LEVEL_ID = ml.LEVEL_ID WHERE blc.ENABLED = 'Y';
• Audit query isolating changes by updater: filter on LAST_UPDATED_BY and LAST_UPDATE_DATE.
• Context resolution: restrict by USER_ID, RESPONSIBILITY_ID, APPLICATION_ID, ORG_ID, or SITE_ID to find the most specific override for a session.
• Coverage reporting: count active customizations grouped by LEVEL_ID to identify over- or under-configured levels.

Because the table is marked as not implemented in 12.1.1, production queries should first verify whether rows exist before relying on the result set.

Related Objects

The following objects are most significant in relation to BIS_LEVELS_CUSTOMIZATIONS:

• MSD_LEVELS — referenced via BIS_LEVELS_CUSTOMIZATIONS.LEVEL_ID; the parent definition of each BIS level.
• FND_USER — join on USER_ID to resolve the affected user.
• FND_RESPONSIBILITY — join on RESPONSIBILITY_ID to resolve the responsibility scope.
• FND_APPLICATION — join on APPLICATION_ID to resolve the application short name.
• FND_ORG / HR_OPERATING_UNITS — join on ORG_ID for operating unit context.
• FND_FORM_FUNCTIONS — join on FUNCTION_ID for function-level customization attribution.
• FND_PAGES / BIS page metadata — join on PAGE_ID where page-level tailoring is recorded.

These relationships make the table useful as a configuration-audit satellite in EBS reporting and integration models.