Results for “bsc_apps_users”

18 results




AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

BSC_APPS_USERS is a table within the Balanced Scorecard (BSC) product family of Oracle E-Business Suite. The BSC module is documented as obsolete in the ETRM reference set, and this table has been identified by the implementation/DBA metadata as not implemented in this database for the documented release. Its declared purpose is to hold "BSC Users" — that is, the set of application user records recognized by the Balanced Scorecard application, presumably for authentication, personalization, and assignment of scorecard-related responsibilities such as scorecard owner, viewer, or administrator.

Under a heuristic Data Vault classification mined from the foreign-key structure, BSC_APPS_USERS is described as satellite-leaning. In practice this suggests it should be modeled as descriptive context hanging off a hub or link rather than as an independently evolving business entity. The single foreign-key relationship — BSC_APPS_USERS.USER_ID referencing BSC_USERS — reinforces that reading: the substantive user identity is owned elsewhere (BSC_USERS), while this table carries additional descriptive attributes about that user within the BSC context.

Key Information Stored

The table is documented with ten columns in the 12.1.1 physical schema, owned by the BSC schema. The primary key, BSC_APPS_USERS_PK, is defined on USER_ID, and a separate unique index, BSC_APPS_USERS_U1, also covers USER_ID. Because the primary key and the only unique index are both on the same single column, USER_ID functions simultaneously as the surrogate key for this table and as the business key joining it to BSC_USERS.

  • USER_ID — surrogate primary key and foreign key to BSC_USERS.USER_ID; the join backbone of the table.
  • USER_NAME — the login or application user name used for identification.
  • FULL_NAME — the display name of the BSC user.
  • ENCRYPTED_USER_PASSWORD — the stored, encrypted credential for the user.
  • EMAIL_ADDRESS — contact address, commonly used for scorecard notifications and workflow.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY — standard EBS audit columns recording when and by whom the row was last modified.
  • CREATION_DATE, CREATED_BY — standard EBS audit columns recording row creation.
  • LAST_UPDATE_LOGIN — the login identifier associated with the most recent update, used for session-level audit traceability.

The audit column set follows the standard Oracle EBS WHO-column convention, which means this table is designed to be maintained by concurrent programs, forms, or APIs that stamp audit context automatically.

Common Use Cases and Queries

The primary practical scenario is resolving BSC user credentials and profile details for scorecard access, and joining BSC user identity to the wider application user population. A representative pattern joins the two documented tables on the documented FK column:

  • SELECT a.user_id, a.user_name, a.full_name, a.email_address FROM bsc_apps_users a, bsc_users u WHERE a.user_id = u.user_id;
  • Reporting on active BSC users and their e-mail addresses for notification distribution lists.
  • Auditing user maintenance activity using LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.
  • Verifying the existence and definition of the primary key and unique index via the data dictionary: query DBA_CONSTRAINTS and DBA_INDEXES for BSC_APPS_USERS_PK and BSC_APPS_USERS_U1.

Because the table is documented as not implemented in the reference database, queries should first confirm existence through ALL_TABLES before being relied upon in a given environment.

Related Objects

  • BSC_USERS — the parent table referenced by BSC_APPS_USERS.USER_ID; the principal join target and the owner of user identity in the BSC schema.
  • BSC_APPS_USERS_PK — the primary key constraint on USER_ID.
  • BSC_APPS_USERS_U1 — the unique index on USER_ID, confirming the one-row-per-user cardinality.
  • FND_USER — the EBS-wide application user repository; relevant when reconciling BSC-specific user records with the global user base.
  • BSC_APPS_USERS itself, when compared to BSC_USERS, forms a satellite-style extension for credentials and contact detail.

Given the obsolete status of the BSC module and the documented absence of this table in the reference database, related-object discovery should be validated independently in any environment where BSC objects remain installed.