Search Results org_access_u1

Overview

INV.ORG_ACCESS is a transactional configuration table in the Oracle E-Business Suite Inventory (INV) schema. It defines the set of inventory organizations that are accessible for login by a given responsibility. Because Oracle EBS supports multiple operating units and inventory organizations within a single application instance, this table acts as the access-control bridge between responsibilities and the organizations they are permitted to work in. A record present in ORG_ACCESS indicates that the referenced organization is explicitly available for the specified responsibility. When no rows exist for an organization, that organization is by default accessible by all responsibilities — a permissive fallback that is important to understand when diagnosing organization-access issues.

From a data-vault modeling perspective, the metadata classifies this object as satellite-leaning. This is a reasonable suggestion: the table keys off a combination of responsibility and organization identifiers and stores descriptive and audit attributes (such as DISABLE_DATE and COMMENTS) around that association, rather than existing as a pure standalone hub or a pure many-to-many link. The row-level detail (disable dates, comments, WHO audit columns) reinforces its character as an attribute-bearing satellite over an access relationship.

Key Information Stored

The table contains 14 columns. Its identity is defined by the unique index ORG_ACCESS_U1, which spans RESP_APPLICATION_ID, RESPONSIBILITY_ID, and ORGANIZATION_ID. This composite forms the business key and, per the documented primary key ORG_ACCESS_PK, the same three columns constitute the primary key. The documentation does not define a separate surrogate single-column key, so the composite itself is the identifying key.

• RESP_APPLICATION_ID — Identifies the application to which the responsibility belongs; part of the composite key.
• RESPONSIBILITY_ID — Identifies the responsibility being granted organization access; part of the composite key.
• ORGANIZATION_ID — Identifies the inventory organization made available; part of the composite key and independently indexed by ORG_ACCESS_N1.
• DISABLE_DATE — The date on which the organization access grant is disabled, enabling time-bound access.
• COMMENTS — Free-text VARCHAR2(240) notes describing the access grant.
• Standard WHO columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, along with REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE, capturing audit and concurrent-program provenance.

Common Use Cases and Queries

The most frequent application is diagnosing why a user cannot access an organization after signing into a responsibility. Administrators and support analysts query the table to confirm whether an explicit grant exists or whether the permissive default applies. A typical pattern retrieves all organizations granted to a responsibility:

• SELECT ORGANIZATION_ID, DISABLE_DATE, COMMENTS FROM INV.ORG_ACCESS WHERE RESP_APPLICATION_ID = :app AND RESPONSIBILITY_ID = :resp;
• Joining ORG_ACCESS to FND_RESPONSIBILITY via RESP_APPLICATION_ID and RESPONSIBILITY_ID to resolve responsibility names in a reporting view.
• Filtering on DISABLE_DATE to report active versus expired organization grants.
• Auditing by CREATION_DATE or LAST_UPDATE_DATE to trace when access was provisioned and by whom.

Because a missing row implies universal access, reports that answer "which responsibilities can reach this organization" must account for the empty-set default rather than relying solely on positive rows.

Related Objects

The documented foreign key relationship ties RESP_APPLICATION_ID to FND_RESPONSIBILITY, making FND_RESPONSIBILITY the principal parent for resolving responsibility metadata. ORGANIZATION_ID logically references the inventory organization definition held in ORG_ORGANIZATION_DEFINITIONS, and the third key component is corroborated by ORG_ACCESS_N1. The table is referenced by the APPS synonym ORG_ACCESS and is typically surfaced through organization-access setup and security queries used by the Inventory and general EBS security administration. Join patterns should use the composite of RESP_APPLICATION_ID, RESPONSIBILITY_ID, and ORGANIZATION_ID to preserve key integrity across these dependent objects.