PARTY DATA MODEL

S_PARTY model is the major change seen in Siebel 7.X and later version.

The S_PARTY table is the base table for all the party related entities: Person
(Contact), User, Employee, Partner User, Account, Division, Organization, Partner
Organization, Household, Access Group and User list. Party components have M: M
relationships among them. For each party record stored in the S_PARTY table, the value
of the PARTY_TYPE_CD column denotes the party type. Along with the party type,
extension tables provide the primary differentiation between the different parties.

PARTY DATA MODEL:

PARTY TYPE AND PARTIES:

1) PARTY => PERSON (CONTACT)

PARTY TYPE => PERSON

E.G:

• An employee at the customer company.

• An employee at the competitor’s company

Features:

• A Person is an individual who is represented by a Person record in the database

• Without additional attributes, a Person has no access to your database
The base table (S_PARTY) and extension table (S_CONTACT) that define a contact or
person. A person is the simplest representation of an individual in the database

2) PARTY => USER

PARTY TYPE => PERSON

E.G:

• A registered customer on (your) Web site

• A self-registered partner user, that is, one who has no position.

Features:

• A User is a Person who can log into your database and has a responsibility that
defines what application views are accessible.
• A self-registered partner on a Siebel partner application has a responsibility, but
does not have a position like a full Partner User has.

The base table (S_PARTY) and extension tables that define a user (S_CONTACT and
S_USER) form User Data Model. A User is a person with following added qualities

1) The S_USER table contains a login for this user

2) The S_PER_RESP intersection table specifies the responsibility for this user

3) It is possible to promote a contact to a user. For example, adding a User ID value

for a person in the All Persons view in the Administration – User screen causes the
person to appear as a user in the Users view.

3) PARTY => EMPLOYEE

PARTY TYPE => PERSON

E.G:

• An Employee at your company – An Employee is a User who is associated with a

position in a division within your company

Base table (S_PARTY) and the extension tables (S_CONTACT, S_USER, and
S_EMP_PER) define employee. This includes internal employees and Partner users.

An Employee is a User with the following added qualities:

1. S_EMP_PER provides employee data for this user.

 1. A position defined using the S_POSTN table is typically (but not
necessarily) associated with an employee.
2. If the organization to which the position belongs is not a partner
organization, then the employee is an internal employee.
3. If the organization is a partner organization, then the employee is a partner
user.

4) PARTY => POSITION

PARTY TYPE => POSITION

E.G:

• A job title within (your) company

• A job title within the partner company

Base table (S_PARTY) and extension table (S_POSTN)

Features:

• Position exist for the purpose of representing reporting relationships

• A position within your company is associated with a division and is associated
with the organization to which that division belongs.
• A position can be associated with one division only.
• A position may have a parent position. It may also have child positions
• One or more employees can be associated with an internal position, and one or
more partner users can be associated with an external position.
• An employee or partner user can be associated with more than one position, but
only one position is active at any time.

5) PARTY => ACCOUNT

PARTY TYPE => ORGANIZATION

Account is a company or group of individuals with whom you do business.

An account is typically made up of contacts It can have parent and child accounts.

An account can be promoted to partner organization, but it is not a division, an internal or

external organization.

Base Table (S_PARTY) and extension table (S_ORG_EXT) defines Account data
Model.
6) PARTY => DIVISION

PARTY TYPE => ORGANIZATION

Division is an organizational unit within a company such as Manufacturing or Corporate

unit.

It can also refer to a group of people operating within a particular company.

Features:

A division exists for the purposes of mapping a company’s physical structure into the
Siebel Database and for providing a container for position hierarchies.

A division may have a parent division. It may also have child divisions.

Data cannot be associated directly with a division. (Divisions that are not designated as
organizations do not drive visibility.)

Base table (S_PARTY) and extension table (S_ORG_EXT) define division data model
along with INT_ORG_FLG=Y (in S_ORG_EXT) table

This flag specifies that division is an internal organization.

NOTE: For Account this flag is set to N

7) PARTY => ORGANISATION

PARTY TYPE => ORGANISATION

E.G: An Organizational unit within the company such as Asian organization and

A partner company

Features:

An organization is a division that is designated as an organization.

An organization exists for the purpose of providing a container in which positions can be
associated with data.

An organization can be internal or it can be a partner organization.

A division can be associated with only one organization: itself or an ancestor division that
is also an organization.
Base Table (S_PARTY) and extension tables (S_ORG_EXT and S_BU) define
Organizational data model.

An Organization, sometimes known as a business unit, is also a Division, but has a record
in the S_BU table.

Partner Organization Data Model:

The base table and extension tables (S_ORG_EXT, S_BU, and S_ORG_PRTNR) define
a Partner Organization.

A Partner Organization is the same as an Organization but the flag PRTNR_FLG in

S_ORG_EXT qualifies it as a Partner Organization

8) PARTY => HOUSEHOLD

PARTY TYPE => HOUSEHOLD

Base table (S_PARTY) and household (S_ORG_GROUP) defines Household.

A group of people, typically a family, who reside at the same residence forms Household

A group of purchasers who live in different residences are also included.

Typically, a household is a group of individual consumers who are economically

affiliated and share a common purchasing or service interest.

A household may have any combination of contacts, users, employees, and partner users
as members.

An individual can belong to more than one household.

9) PARTY => USER LIST

PARTY TYPE => USER LIST

Base table (S_PARTY) and extension table (S_USERLIST) defines User list.

E.G:

A support team made up of some internal employees and some partner users.

Features:

A user list is an ad hoc group of people. It may have any combination of contacts, users,
employees, and partner users as members
A user list cannot have a parent or children.

10) PARTY => ACCESS GROUP

PARTY TYPE => ACCESS GROUP

Base table (S_PARTY) and extension table (S_PARTY_GROUP) defines access group

E.G:

Partner IT service providers and business-to-business customer companies that buy

networking equipment.

An access group is a group of any combination of parties of type Position, Organization,

and User List. That is, it is a group of groups

An access group may have a parent access group. It may also have child access groups.

Parties relation to each other:

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.
• For purposes of granting visibility to data, associations of parties of type Person
with other types of parties are stored using the S_PARTY_PER table. 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 S_PARTY_REL table. 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.

Doubts
Hi thanks for this information but I would like to know why this Data model was
designed. what are the uses from database point of view for such arrangement of Party
related data… what do we achieve making the S_PARTY base table for all the related
tables?
Below points will help u
1) The main objective of introducing party model is to provide better access control
mechanism and to improve performance of the system.

The introductions of Party model following tables are made obsolete in Siebel 7.

* S_EMPLOYEE now merged into S_CONTACT

* S_EMPLOYEE_ATT
* S_ORG_INT now merged into S_ORG_EXT
* S_ORG_INT_ATT
* S_POSTN_RPT_REL

2) It allows the configuring the business components related to access control and import
access control data.

3) To introduced the concept of the relational database to a very good access control
mechanism functionality in siebel.

4) The data redundancy was removed , now the we have a master base table which
further linked to various tables for the entities as discussed in article

Still I have few Qs. :-)

1) Prior Siebel 7.0 you said there were 2 tables

S_EMPLOYEE now merged into S_CONTACT
S_EMPLOYEE_ATT, what was
S_EMPLOYEE_ATT being used for?

2) User Lists and Access Groups facilities were not in Siebel 6?If they were there how
were they implemented?
3) Please elaborate more as how the Data Redundancy was removed with introduction of
the Data model…(May be I am not getting clarity in terms of Database concepts here!)

Hello Ashay,

1) S_EMPLOYEE_ATT: This table was used to stored additional detail information

regarding employee
.

2) I am not sure about this, but will update you soon on this.

3) In siebel 7 their was not much major in business layer but the data layer was changed
to a major extent. In siebel 7.x they introduced administrative consoles were you can
easily provide access to the various views and responsibilities etc. But in siebel 6.x there
was not any such concept. The other major change was in siebel 6.x these S_view ,
s_resp etc these tables exists but they were having the explicit joins and in siebel 7.x they
have implicit joins.
The data redundancy was removed with these implicit joins having 1:M relationship
among the parent and child entities.

Thanks
Mandeep Singh Grewal