Search Results hz_party




Overview
Explore in AI Chat

Overview

APPS.HZ_GROUP_WF_USER_ROLES_V is a reporting view in the Oracle E-Business Suite Trading Community Architecture (TCA) model. It exposes party relationships that exist between person parties and group parties in a form compatible with the Oracle Workflow / SOA role and user model. Specifically, the view maps each person-to-group relationship as a "user" (the person) membership of a "role" (the group). The view is commonly used by Workflow notification routing, Oracle Approvals Management, and any integration layer that needs to enumerate the members of an HZ group party by using Workflow-style USER_NAME/ROLE_NAME identifiers.

Because the underlying TCA tables (HZ_PARTIES, HZ_RELATIONSHIPS) are not directly consumable by Workflow role resolution, this view performs the necessary translation by concatenating the party identifier with the entity prefix ("HZ_PARTY:" or "HZ_GROUP:") and by joining through the relationship definition. The view is defined in the APPS schema and is available across 12.1.1 and 12.2.2. The PARTITION_ID value of 8 and the SECURITY_GROUP_ID of NULL indicate that this is a system-level, non-MOAC-wrapped view.

Underlying Base Objects

The ETRM metadata documents two referenced base objects, both exposed as synonyms in the APPS schema:

  • HZ_PARTIES (SYNONYM) — the TCA party master. It is joined twice: once as SP (subject party / person) and once as OP (object party / group).
  • HZ_RELATIONSHIPS (SYNONYM) — the relationship definition linking subject and object parties, providing the relationship type, effective dates, and status.

The view joins HZ_RELATIONSHIPS.SUBJECT_ID to the person party and OBJECT_ID to the group party, filtering subject parties to party_type = 'PERSON' and object parties to party_type = 'GROUP'. Outer-join syntax ((+)) is applied on SUBJECT_TABLE_NAME and OBJECT_TABLE_NAME to bind the join explicitly to the HZ_PARTIES table. Rows are restricted to active or inactive parties and relationships (status of 'A' or 'I').

Key Columns

  • USER_NAME — the person party rendered as 'HZ_PARTY:'||party_id. This is the Workflow user identifier.
  • USER_ORIG_SYSTEM and USER_ORIG_SYSTEM_ID — the originating system and party ID for the person.
  • ROLE_NAME — the group party rendered as 'HZ_GROUP:'||party_id. This is the Workflow role identifier.
  • ROLE_ORIG_SYSTEM and ROLE_ORIG_SYSTEM_ID — the originating system and party ID for the group.
  • START_DATE and EXPIRATION_DATE — effective dates of the relationship, mapped from HZ_RELATIONSHIPS.START_DATE and END_DATE.
  • SECURITY_GROUP_ID — always NULL in this definition; no MOAC operating unit restriction applies.
  • PARTITION_ID — constant 8, identifying the partitioning group of the view.

Crucially, an analytic RANK() OVER (PARTITION BY subject_id, object_id ORDER BY relationship_id DESC) is computed and named RELRANK. The outer query filters relrank = 1, so only the most recent relationship between a given person and group is returned. This prevents duplicate user/role pairs where historical relationship rows exist.

Common Use Cases and Queries

Typical scenarios include resolving the members of an approval group, populating Workflow role assignments, or auditing person-to-group memberships.

To list all members of a specific group party:

  • SELECT user_name, user_orig_system_id FROM hz_group_wf_user_roles_v WHERE role_name = 'HZ_GROUP:'||:party_id;

To find all groups to which a person belongs:

  • SELECT role_name, role_orig_system_id FROM hz_group_wf_user_roles_v WHERE user_name = 'HZ_PARTY:'||:party_id;

To inspect effective membership windows:

  • SELECT user_name, role_name, start_date, expiration_date FROM hz_group_wf_user_roles_v WHERE expiration_date IS NULL OR expiration_date > SYSDATE;

Because the view already deduplicates by relationship rank and filters status, it is generally safe to query directly without additional DISTINCT clauses. Integrations should treat the concatenated USER_NAME and ROLE_NAME values as stable identifiers, as they are derived deterministically from the TCA party IDs.