Siebel Database Upgrade Guide > Siebel Database and UI Upgrade Planning >

Upgrade Planning for Siebel Access Control

Upgrades from: Siebel 6.x & 7.0.x.

Environments: Development, production test, production.

Databases: All databases.

Platforms: MS Windows, UNIX, IBM z/OS.

Access control was significantly revised in Siebel 7.5. Access control refers to all mechanisms that control visibility of screens, views, and data within Siebel Business Applications. Access control includes, but is not limited to positions, responsibilities, organizations, and access groups.

To implement access control within your Siebel Business Applications, your Siebel administrator creates relationships between people and resources (a more general term for data that includes views and functionality). These relationships or policies are authorizations. Both people and resources can be grouped and placed in hierarchies to simplify administration.

External users, such as customers and channel partners, can be assigned varying access levels that control visibility of data and application functionality. When planning access policies, consider the following:

• The complexity of access control policies (one data item or group of data items can be accessed by one or many users or groups, but not by all).
• The amount of content that is distributed by the Siebel Business Applications, including Master data (data that is static and referential, such as Products) and Customer data (data that is created and managed by users of applications, such as Opportunities).
• The number of users and entities that access the data. Also consider the complexity of relationships between users (partners, competitors, browsers, customers).

For more information on access control, see Security Guide for Siebel Business Applications.

Person, Household and Service Request Visibility

Beginning with Siebel 7.5, Person, Household, and Service Request can be made visible to multiple organizations, also called Business Units. Siebel 7.5 introduced several new tables to support this:

• S_CONTACT_BU
• S_ORG_GROUP_BU
• S_SRV_REQ_BU

The upgrade to Siebel 7.7 populates the S_CONTACT_BU, S_ORG_GROUP_BU, and S_SRV_REQ_BU tables with one record for each record in the S_CONTACT, S_ORG_GROUP, and S_SRV_REQ tables. After the upgrade, Contacts, Households, and Service Requests continue to be visible from the Business Unit they belonged to before the upgrade.

Access Group and Userlist Attributes

In Siebel 7.5, two new Siebel Extension tables were added to the S_PARTY, S_PARTY_GROUP and S_USERLIST tables to hold Access Group and User List attributes, respectively.

The upgrade to Siebel 7.7 adds records to the S_PARTY_GROUP and S_USERLIST tables for existing S_PARTY Access Group and User List records.

To support Multi-Org visibility, the upgrade also adds corresponding intersection table records to the S_PARTY_GRP_BU and S_USERLIST_BU tables.

Technical Note 312 provides guidance and best practices for implementing access control. This Technical Note includes background information about the Access Group access control mechanism implemented in Siebel 7, discusses migration considerations, and outlines steps for deploying Access Group access for Siebel Business Applications.

For detailed information about access control, see Security Guide for Siebel Business Applications.

Content Categorization

Product categorization was available in the Siebel 6.x data model. Siebel 7.x expands this to support categorization of content such as auction items and literature items.

Categorizing content simplifies access control policy design and management. System administrators can specify access to a set of content items. This makes the content more searchable and accessible to users through navigation.

In Siebel 6.x, categories could be shared across multiple catalogs and could have multiple parents. In Siebel 7.x, a category can belong only to one catalog and have at most one parent catalog.

To accommodate this change, the database upgrade generates copies of categories and category hierarchies that were previously shared across multiple catalogs.

For example, if Catalog-A and Catalog-B both share Category-1, then after the upgrade, Category-1 will not be shared. Instead, there will be two copies of Category-1. One copy will belong to Category-A. The other copy will belong to Category-B.

For more information about categorization, see Security Guide for Siebel Business Applications.