Bookshelf v7.5: How Parties Relate to Each Other

Security Guide for Siebel eBusiness Applications > Access Control > Access Control Overview >

How Parties Relate to Each Other

Parties have some required relationships, as described below.

Divisions, organizations, and accounts are instances of the Organization party type.

A division, internal or partner, is also an organization if its internal organization flag is TRUE (INT_ORG_FLG = "Y") and it has an associated S_BU record.

Every division is associated with one organization: either itself or the closest ancestor division that is also an organization.

Every position is associated with a division. The position is then also automatically associated with one organization: the organization with which the division is associated.

Persons (contacts), users, employees, partner users are instances of the Person party type.

Typically, you associate each employee and partner user with one or more positions. The employee or partner user has only one active position at one time. The employee or partner user is automatically associated with one division and one organization at a time—the division and organization associated with the active position.

CAUTION: Merging employee records is not recommended. You may disrupt party relationships to a significant extent and get unexpected results.

For purposes of granting visibility to data, associations of parties of type Person with other types of parties are stored using the table S_PARTY_PER. For example, accounts are associated with contacts, users are associated with positions, and so on. A user associated with a position can see data for accounts or opportunities assigned to the position (when this is the active position). Relationships stored in S_PARTY_REL also affect data routing for mobile users.

For purposes of storing ad hoc, informational relationships between parties, such associations are stored using the table S_PARTY_REL. For example, a company and its accounting firm may both be stored as accounts. Assuming that your application provides the capability to define this relationship, it can be stored in the S_PARTY_REL table.

Ad hoc and informational relationships between parties are stored in the table S_PARTY_REL. For example, a company and its accounting firm may both be stored as accounts. The relationship between these two accounts can be stored in the S_PARTY_REL table, assuming that your application has been configured to define these relationships.