HZ_RELATIONSHIPS
Generic party-to-party relationship — e.g. a person party related to an organization party as its contact.
Key Columns
Common Joins
HZ_PARTIESvia SUBJECT_ID = PARTY_IDThe subject party of the relationship — for a contact relationship, this is the person.
HZ_PARTIESvia OBJECT_ID = PARTY_IDThe object party of the relationship — for a contact relationship, this is the organization the person is a contact for.
HZ_ORG_CONTACTSvia RELATIONSHIP_ID = PARTY_RELATIONSHIP_IDContact-specific role attributes (job title, decision-maker flag) layered on top of a contact-type relationship.
Used In
Notes
A relationship row alone only says two parties are connected — RELATIONSHIP_TYPE/RELATIONSHIP_CODE (e.g. CONTACT) says how. Getting from a bare HZ_RELATIONSHIPS row to a usable 'contact of this org' record means also joining HZ_ORG_CONTACTS.
Related
Party contacts (people) for a customer/organization
A 'contact' in TCA is a person party related to an organization party — never a single 'HZ_CONTACTS' table, and HZ_PARTY_SITES is not it either (that's addresses only, no phone/email). The relationship itself lives on HZ_RELATIONSHIPS (SUBJECT_ID = the person's PARTY_ID, OBJECT_ID = the organization's PARTY_ID, RELATIONSHIP_TYPE identifying it as a contact relationship), specialized by a HZ_ORG_CONTACTS row (PARTY_RELATIONSHIP_ID = the relationship, plus role attributes like JOB_TITLE). The contact person's actual phone/email lives separately on HZ_CONTACT_POINTS (OWNER_TABLE_ID = the person's PARTY_ID, OWNER_TABLE_NAME = 'HZ_PARTIES', CONTACT_POINT_TYPE = 'PHONE' or 'EMAIL'). So a full 'contacts with phone/email for this org' query joins HZ_PARTIES (org) -> HZ_RELATIONSHIPS -> HZ_ORG_CONTACTS, plus HZ_PARTIES again (for the contact's own name) -> HZ_CONTACT_POINTS (for that contact's phone/email) — five tables, not three.