Results for “per_scorecard_sharing”

50+ results




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

Overview

PER_SCORECARD_SHARING is a Human Resources (PER) module table in the Oracle E-Business Suite HR schema. As its documentation states, the table holds access permissions defining which people can access which scorecard. It functions as the authorization bridge between scorecard definitions and the individuals or roles granted visibility to them, and it is a core dependency for scorecard-based talent management, performance, and workforce intelligence features delivered through Oracle HRMS self-service and manager self-service (MSS) flows.

The ETRM metadata classifies this object heuristically as standalone within a Data Vault modeling context. In Data Vault terms, this suggests it is best treated as a standalone construct rather than a pure hub, link, or satellite. In practice, the table behaves like an access-control link: it associates a scorecard with a person and carries descriptive and audit attributes around that association. The classification is a modeling suggestion mined from the foreign-key structure, not a hard schema constraint.

Key Information Stored

The table is physically owned by HR and contains 40 documented columns in ETRM 12.2.2. The most consequential columns are:

Two unique indexes are documented. PER_SCORECARD_SHARING_PK (SHARING_INSTANCE_ID) is the true primary key. PER_SCORECARD_SHARING_UK1 (SCORECARD_ID, PERSON_ID) is the business-key candidate, enforcing that a given person appears at most once per scorecard. This composite uniqueness is the most important integrity rule to understand before any insert or data migration.

Common Use Cases and Queries

The table is queried whenever applications or reports must determine who can see a particular scorecard, or conversely, which scorecards a person can see. Typical scenarios include manager self-service dashboards that must filter scorecard content by viewer, security reviews of scorecard visibility, and reconciliation reports confirming that expected users have been granted access.

Representative lookup pattern:

  • To find all persons granted access to a scorecard: SELECT person_id FROM per_scorecard_sharing WHERE scorecard_id = :p_scorecard_id;
  • To list the scorecards visible to a person: SELECT scorecard_id FROM per_scorecard_sharing WHERE person_id = :p_person_id;
  • To audit recent grants: query CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE filtered by a date range.

Because the unique key spans SCORECARD_ID and PERSON_ID, duplicate grants should be pre-validated before bulk loads, and OBJECT_VERSION_NUMBER should be respected during updates to preserve concurrent-update integrity.

Related Objects

The table participates in the broader PER scorecard and person data model. The most significant related objects and join columns are:

  • PER_PERSON_ANALYSES — Often the parent anchor of a scorecard definition, joined via SCORECARD_ID to ANA_ANALYSIS_ID or the equivalent scorecard identifier.
  • PER_ALL_PEOPLE_F — The primary person/employee view, joined on PERSON_ID = PERSON_ID to resolve the grantee's identity and assignment context.
  • PER_SCORECARDS / scorecard definition objects — Supply the scorecard metadata resolved through SCORECARD_ID.
  • PER_OBJECTS and PER_SCOREBOARD / scoreboard objects — Related PER objects that surface scorecard content to viewers whose access is governed here.
  • PER_SCORECARD_SHARING public API / scorecard administration processes — Application-tier logic that inserts, updates, and deletes rows in this table as administrators grant or revoke scorecard access.

Querying PER_SCORECARD_SHARING alongside PER_ALL_PEOPLE_F is the standard method for producing user-facing accessibility reports in Oracle EBS 12.1.1 and 12.2.2.