Tech 312

The Leader in eBusiness
S I E B E L S Y S T E M S , I N C .
Access Control
Upgrade and
Migration Guide for
Siebel 7
12/21/01 Siebel Systems, Inc. Confidential and subject to change

The contents of this document are confidential and proprietary to
Siebel Systems, Inc.
Revision History:
Date Author Description
7/ 01/2001 B. Garrett Reynolds, Original creation
Senior Configuration
Specialists – Expert
Services
2
Table of Contents
REVISION HISTORY:.........................................................................................................................2
TABLE OF CONTENTS ......................................................................................................................3
ABOUT THIS DOCUMENT................................................................................................................4
INTRODUCTION.................................................................................................................................4
WHAT IS ACCESS CONTROL?.........................................................................................................5

RESPONSIBILITIES .................................................................................................................................5
POSITIONS............................................................................................................................................5
ORGANIZATION (MULTI-ORG) ..............................................................................................................6
ACCESS GROUP ....................................................................................................................................7
Figure 1. Reseller Community and Reseller Resources Catalog Logic ...........................................10
Figure 2. Reseller Resources Access Control.................................................................................10
SIEBEL 7 DATA MODEL .................................................................................................................13
ADDITIONAL ENHANCEMENTS ...................................................................................................17
REMOTE USERS ...............................................................................................................................18
UPGRADE ISSUES.............................................................................................................................19
MULTI-ORG VS. ACCESS GROUP.................................................................................................20
PLANNING AND DESIGN ................................................................................................................22

CUSTOMERS CURRENTLY USING MULTI-ORG WHO ARE IMPLEMENTING ACCESS CONTROL .....................23
CUSTOMERS NOT CURRENTLY USING MULTI-ORG WHO ARE IMPLEMENTING ACCESS CONTROL ..............26
CUSTOMERS CURRENTLY USING MULTI-ORG WHO ARE REMAINING WITH MULTI-ORG AND NOT
IMPLEMENTING ACCESS CONTROL ACCESS GROUP ...............................................................................28
ADMINISTRATION AND SETUP ....................................................................................................30
ASSIGNMENT MANAGER...............................................................................................................32
TERMINOLOGY ...............................................................................................................................33
APPENDIX A ......................................................................................................................................34
OUTSTANDING .....................................................................ERROR! BOOKMARK NOT DEFINED.
3
About this document
The purpose of this document is to provide customers with guidance and direction on the best practices for
upgrading-migrating to 7 specifically around the implementation of Access Control. This document
provides background on Access Group, a new access control mechanism implemented in Siebel 7, and
outlines steps to deploying Access Group access into Siebel eBusiness applications (customer and
employee facing applications). It assumes that the reader is familiar with Siebel application architecture.
It is intended to help Siebel professionals understand Access Group access control mechanism so that they
can properly design and implement proper Access Control designs. This document is intended for
internal and external personnel who are directly involved in the implementation and design of Siebel
eBusiness applications specifically around the Access Control technologies (customer system
administrators, knowledge management experts, Siebel Sales Consulting, Product Marketing, and
Technical Services)
Introduction
Deploying Siebel eBusiness applications over the web channel allows external users, such as customers
and channel partners, with varying access levels, to directly access data and application functionality.
This introduces a new set of data and content access dynamics that our current mechanisms for visibility
are not created for. These dynamics include:
• An exponential increase in the amount of content (Master Data like Products, and Customer Data
like Opportunity) that will be distributed via the Siebel application.
• An exponential increase in the number of users and entities that will access the data and added
complexity of relationships between users (partners, competitors, browsers, customers).
• Significant increase of complexity in access control policies (one data item and group of data
items can be accessed by one or many users and groups, but not by all; and vice versa).
Siebel customers require Siebel eBusiness applications (customer and employee facing applications) to
provide a framework for safely delivering content and application functionality over the web channel and
web client for enterprise applications, but are running into the following limitations with the current 6.x
solution:
• The current model for visibility control cannot be administered for either large numbers of users
with varying access levels or large numbers of content items.
• The current model for visibility does not provide the level of control required to protect partner
data and still maintain a single view of the customer.
Access Group Access Control Mechanism is one solution to these business problems faced by customers,
with the following benefits:
• Data organizing mechanism provided – data access control at the Category and Catalog level
− Extends the Category and Catalog concept; offers capability to organize master data into
hierarchical structure (7), using catalogs and categories. Customer data will be added to the
Access Group functionality in future releases.
− Significantly simplifies the work for system admin:
− Huge amount of data is easier to access and administer in a hierarchical structure;
4
− Only need to add a new data item into a Category and access control is effective
• Access Group provided as a mechanism for grouping Positions, Orgs, Accounts, Business Units,
and User Lists, each of which contains 1 or many persons
− Significantly simplifies the work for system admin for large number of user
administration – only need to add a new person into a party entity, and access control is
effective
• High flexibility allows for any arbitrary association between Categories and Access Groups
− Good at handling complicated and multiple Access Control rules and policies
Today, many customers have deployed Siebel 6.X products, many of who have deployed Multi Org
functionality to various business objects. For new customers that are in the process of planning for access
control deployment, they need to carefully analyze their Access Control requirements and how Access
Group and Multi Org fit in to this picture. For those customers who have already Multi Org’ed certain
data objects, they need to rethink about the access control in the context of Access Group. This document
is intended to provide guidelines for the customer’s access control planning process.
For a detailed description of Access Group and Multi Org please refer to the Access Control
Documentation.
What is Access Control?

Access Control refers to ALL mechanisms to control visibility within Siebel eBusiness applications. This
includes but is not limited to Positions, responsibilities, Organizations, and Access Groups. Access
control is simply creating relationships between people and resources (a more general term for data that
includes views and functionality). These relationships or policy are authorizations. Both people and
resources can be grouped and placed in hierarchies to ease the administration.
Responsibilities
Responsibility Access controls access to data at the level of views and screens. In reality, business
enterprises are often organized around functions – engineering, marketing, sales, business development,
finance, etc. Employees inside of these enterprises typically fall into one or multiple of these functions. An
employee belonging to one function may not want to, or shouldn’t be allowed to access data that belong to
another organization. Example: As a marketing manager, one shouldn’t see the sensitive corporate
financial data; as an engineer, one may not want to see all the marketing materials at all. Responsibility
Access is designed in this context to control access according to business functions. This option is
relatively easy to implement, but lack of granularity in data control is a major drawback
Positions
Position Access controls access to data at the level of individual data items, and applies only to Customer
Data (objects like Opportunities, Contacts, Accounts, etc.), not to Master Data (objects like Products,
Literature, etc.). Position Access works in two different contexts – hierarchical and team based.
5
This option offers much more granularity in data control than Responsibility Access, but is limited in the
following aspects:
1. Lack of Data organizing mechanism: all data access control is at the record level – Admin nightmare
when having to manage a huge amount of data (however, because of the nature of Customer Data
(which Position Access handles) – small in number, this fortunately wouldn’t be too bad.
2. Sales and Contact Teams are not re-usable: for each data record a system admin needs to build from
ground a new team – Very Poor Scalability means administration nightmare when dealing with huge
amount of data.
3. One record can only have one Sales and Contact Team – Cannot handle complicated and multiple
Access Control policies.
Organization (Multi-Org)
Like Position Access, Organization Access controls access to data at the level of individual data items. In
the real world, access to data often depends on which (physical) organization one belongs. Example:
Siebel sales consultants work closely with many Siebel Partner organizations such as ABC and XYZ to
deploy Siebel products. ABC should be able to see certain data that they are work on, but they should
never be allowed to see what XYZ is working on, like what price XYZ charges its client. Organization
Access is created in this context to control access along the lines of organizations.
In Siebel 2001, Organizations can be placed into a hierarchy. This differs from Siebel 2000, where
Organizations were flat and could not have parents. There is also a new Sub-Org view mode, which
displays customer data for the user's Organization and any Organizations below it in the Organization
hierarchy.
Complex organizations benefit from having the ability to place their internal Organizations into a
hierarchy and provide a view to some users which shows data down the hierarchy. The eChannel
application also benefits from this enhancement because some of our customers who deal with large,
complex Business Partners structure them into Organization hierarchies with HQ, Regional Branches,
local branches, and so on. Providing a view for the regional manager to see data associated to his branch
and all of those below is a great enhancement.
In Siebel 2001, many more objects have been Multi-Org enabled.
Multi-Org Enabled Objects

• Account*
• Competitor*
• Partner*
• Opportunity*
• Order*
• Quote*
• Cost List and Rate List*
• SmartScript
• Product
• Literature
• Price List
• Responsibility
Single-Org Enabled Objects

• Contact
• Consumer
6
• Service Request
• Service Agreement
• Asset
• Employee
• Position
• Division
*Multi-Org Enabled in 7
This option offers much flexibility for data access control at the organization level and meets the business
requirement in reality, but its usability is limited due to the following constraints:
1. Lack of Data organizing mechanism: all data access control is at the record level – Admin nightmare
when having to manage a huge amount of data
2. Creating Organizations is not flexible: Organizations have specific meaning and are typically not
appropriate for ad hoc groups; creating Organizations is complicated: have to create positions, etc. for
Org-based visibility to take effect.
3. Prior versions of Siebel did not provide for a hierarchical inheritance feature in Multi-Org, for
example,, the hierarchical structure between different organizations is not considered in Organization
Access. The Siebel 7 product release introduces Sub-Org visibility which provides the hierarchical
inheritance that previous Siebel versions lacked. But Multi-Org still does not handle complicated
Access Control Rules.
Access Group
Access Group Access Control Mechanism offers new features to address maintenance and visibility issues
of large, complex customers.
The Access Group Hierarchy is a new feature that allows an Administrator to set up groups and assign
people to them indirectly through Positions, Organizations, Accounts, Households, and User Lists. A
person cannot be directly associated to an Access Group. The groups can be organized into a hierarchy.
A new mechanism is introduced in Siebel 7 that allows visibility to data through being a member of an
Access Group. This Access Control mechanism is only available for Master data in 7.0, which are things
like Products, Literature, Price Lists, Auction Items, Courses, and Decision Issues. These objects
typically have large set of records that is relatively static.
Why Another Visibility Mechanism? Some companies have millions of records in the Product or
Literature tables. On the other side, there could be a huge amount of people and Organizations to relate to
this data. A large, complex customer like XYZ has over 50,000 employees, over 100,000 Partners, and
potentially millions of contacts targeted to use their Siebel applications.
There are more complexities that can be introduced into the equation. A partner can have a different level
of access like Silver, Gold, and Platinum, which allows them a broader access to data. Or one may want
to grant different levels of access to employees within a Partner Organization, depending on profile data
for instance.
One of the major benefits to having Access Groups is that it’s easier to maintain access to content. The
traditional Access Control mechanisms required an Administrator or Assignment Manager to touch each
7
and every record in order to relate each instance to a person or Organization. This is why a new Access
Control mechanism is introduced.
The other major benefit to categorization of data, besides the ease of administration, is that it also makes
navigation by end users through the data much easier. Another benefit is that by creating the Access
Group hierarchy, child groups have access to data down the hierarchy. This means that groups can see
data to which their parents, grandparent, and so on up the chain, have access.
Categorization of Content is another new feature. Although categorization of data was available in
prior versions, it wasn’t tied to visibility until Siebel 2001. This categorization refers only to master data
(examples being Products, Literature, Solutions, Price Lists) in Siebel 7. This feature allows an
Administrator to create classifications and associate instances of data to these categories. These can also
be set up in a hierarchy.
The benefits to categorizing data are that it simplifies Access Control administration. Also, data is more
manageable when grouped into categories. In prior versions, there was just a flat list of records like the
Product and Literature screens where a user would need to query for keywords with wildcards to try and
locate the correct record and then scroll through the list to find the exact match. The categories help
organize the data and assist in locating the correct record faster and easier than before.
Catalogs and Categories are created to represent classifications for the master data. It is up to the
customer to decide what these catalogs and categories will be. The Catalog is really just a root directory
and not used for visibility. The Categories can be arranged in a hierarchy. Then master data items are
related to the categories. Products, Literature, and any other master data can be related to the same
category. As stated before, prior versions of Siebel had the ability to categorize data into Catalogs and
Categories, but it wasn’t used for visibility. Another difference is that a Category could be related to
multiple Catalogs before. The new design for 7.0 does not allow for this and a Category can only belong
to one Catalog.
Categories are marked either public or private. If the category is Public, it is visible to everyone. If the
category is Private, Access Group visibility it is applied. The private attribute is downward overriding. If a
catalog or a parent category is marked private, all its children categories will be automatically marked as
private and cannot be changed back to public if the parent category remains private. The public attribute is
not overriding. A catalog or a parent category can be public whereas some of its children categories are
marked private. When originally marking a catalog or category private but then change it back to public,
the categories below that specific catalog and category remain private until manually change them to
public.
Categories can be associated to the Access Groups once master data has been organized into categories,
and persons to Access Groups indirectly through Position, Organization, Account, Household, and User
List associations. Having access to a category means having access to all the Master Data items contained
in the Category.
On the Access Group side, a user will have access to categories to which a parent Access Group is
related through the Access Group hierarchy. This is enabled via that denormalized Access Group
relationship that is stored in the S_PARTY_RPT_REL table.
This upward inheritance feature embedded in Access Group hierarchy is run-time enforced. In an
administrative view, when a parent Access Group is associated with a category, its children Access
Groups will not be explicitly associated with that particular category. Users cannot disassociate the
children Access Groups from the category because the association is not displayed at all. However, the
8
application will run-timely determine that a user can access that category by verifying that the user
belongs to or is a member of the child Access Group to the Access Group which is associated with the
category.
Upward inheritance in Access Group hierarchy is not an optional feature. There is no switch to turn off
the upward inheritance capability of a child Access Group.
On the data side, an Access Group may also have visibility down a category tree if the Administrator
selects to cascade the category. When cascade for a parent category is ticked, all its children directories
are visible to the Access Group associated. Although cascade is displayed in a field format, it functions as
a button because there is no “cascade” column in the data table. Un-tick cascade will not disassociate the
children categories from the Access Group. In such a case, cascade delete functionality is available if an
Administrator removes an Access Group’s from a catalog and category – by doing this, he effectively
removes this access group from all children categories.
Cascade is development-time enforced, which means the Access Group is explicitly associated with the
children categories when ticking the “Cascade” field.
Access Group Access Control offers the most flexibility for data access control and provides the following
benefits.
1. Provides Data organizing mechanism – data access control is at the Category and Catalog level
2. Significantly simplifies the work for system admin – only need to add a new piece of data into a
Category and access control is effective
3. Provides Access Group as a mechanism for grouping Positions, Orgs, and User Lists – which contains
1 or many persons
4. Significantly simplifies the work for system admin – only need to add a new person into a party
entity- access control is effective
5. High flexibility allows for any arbitrary association between Categories and Access Groups
6. Good at handling complicated and multiple Access Control Rules
An Application of Access Group Access Control
Let’s look at a real-life business scenario. Assume one wants to use the level of their resellers to determine
which of the “knowledge” resources they have access to. The resellers include partner organizations and
some individual consultants that are not associated with a partner organization.
The solution must meet the following requirements:

§ Provide the base resellers access to basic product information resources: service FAQs, product
documentation, and product training classes.
§ In addition to basic product information, provide the “premier” resellers access to more sales-specific
resources: marketing FAQs, documents that provide guidance on customer decision issues, and sales
training classes.
§ In addition to product and sales resources, provide strategic resellers access to resources to help
design entire marketing campaigns: competitive briefs and training classes.
§ As the status of a reseller changes, the administration required to change the reseller’s access to data
must be minimal.
9
Figure 1 illustrates the logical relations of Reseller Community and Reseller Resources Catalog, and how
they should be associated. Figure 2 illustrates one access control structure that solves this simple business
problem.
Figure 1. Reseller Community and Reseller Resources Catalog Logic
Product Resources
Strategic
Premier
Sales Resources
Base
Planning
Resources
Figure 2. Reseller Resources Access Control
Resellers Community
BASE RESELLERS
Partner 6, Partner 7, Partner 8, User List 3
PREMIER RESELLERS
Partner 3, Partner 4, Partner 5, User List 2
STRATEGIC RESELLERS
Partner 1, Partner 2, User List 1
10
Reseller Resources Catalog
PRODUCT RESOURCES
Service FAQs (Svc FAQ 1, Svc FAQ 2, ...)
Product Training (Class 1, Class 2, ...)
Product Documentation (WP 1, WP 2,...)
SALES RESOURCES
Marketing FAQs (Mktg FAQ 1, Mktg FAQ
Decision issues (DI 1, DI 2, ...)
Sales Training (Class 3, Class 4,...)
PLANNING RESOURCES
Competitive Briefs (CB 1, CB 2,… )
Marketing Training (Class 5, Class 6,… )
This solution assumes that the resellers are stored as organizations, in which employees are associated
with positions. The consultants exist as users. That is, they have responsibilities, but not positions, and are
not associated with an organization (when they log in however, dynamically they are associated with an
organization through PROXY Employee to have a Position. For more refer to Authentication and Access
Control Administration Guide, Siebel 7, for more).
The Resellers Community is an access group hierarchy. Each node is an access group whose members are
reseller organizations and a single user list. The user list in each node contains all consultants of the
appropriate status.
The Reseller Resources catalog is constructed of categories containing data and nodes that are empty
categories to define levels in the hierarchy.
Apply the following principles to construct this structure:

§ Construct the Resellers Community such that the upper level resellers have the least access to
resources. Thus, the BASE RESELLER access group is the parent of the PREMIER access group,
which is in turn the parent of the STRATEGIC RESELLER access group. Because of upward

inheritance, STRATEGIC RESELLER can access all resources visible to PREMIER RESELLER and
BASE RESELLER.
§ Construct the Reseller Resources Catalog such that the least restricted resources are visible to all.
Product resources are available to all resellers, so the PRODUCT RESOURCES node is at the top.
Categories of PLANNING RESOURCES and SALES RESOURCES are children nodes to the
PRODUCT RESOURCES node. The PLANNING RESOURCES category is child nodes to the
SALES RESOURCES category.
The following implementation procedure effectively restricts the base resellers’access to product resources
only, premier resellers’access to product resources and sales resources; and strategic resellers’access to
all resources.
To implement this structure
1. Construct the Reseller Resources Catalog, and specify it as private, with access provided to the BASE
access group. Access to the catalog is also granted to the PREMIER and STRATEGIC RESELLERS
access groups because access group access is upward inherited.
2. Associate the BASE access group with the PRODUCT RESOURCES category. Make sure that the
cascade feature in this category is turned off. This gives all nodes in the Resellers Community access
to PRODUCT RESOURCES, but not other resources, in the Reseller Resources Catalog.
3. Associate the PREMIER access group with the SALES RESOURCES category. Make sure that the
cascade feature in this category is turned off. Now the PREMIER node and its descendant node, the
STRATEGIC RESELLER access group, have access to the SALES RESOURCES category.
4. Associate the STRATEGIC RESELLERS node with the PLANNING RESOURCES category. Now
only the STRATEGIC RESELLERS node has access to all three categories in the Reseller Resources
Catalog.
This structure meets the minimal maintenance requirement. If the status of a partner organization
changes, add the partner to the appropriate access group and delete the partner from the old access group.
If the status of a consultant changes, add the user to the appropriate user list, and delete the user from the
old user list. Re-categorized consultants and employees are granted appropriate new access as defined by
the structure.
This is only one option that one can use to implement their access control plan; there are many other
options available, specially attention however, should be paid to the aforementioned features such as
upward inheritance, downward cascade, etc.
12
Siebel 7 Data Model
There have been several major data model changes in the Siebel 7 release. The largest data model change
was for the Party and Single Person model, which is fundamental to the entire Siebel 7 release. This new
model was not done specifically for the Access Control mechanism, but Access Control does benefit from
it. With the new model, Accounts, Organizations, Internal Divisions, Contacts, Employees, Positions, and
Households are all considered Parties and can be referenced from the same table, S_PARTY. The prior
tables that housed these data entities still exist and are still used, but they are now extension tables to the
new base table and the data is brought into the business components through an implicit join. The other
two major data model changes are also related to this new model. Employees and Contacts have been
combined into the same table (S_CONTACT) and similarly, internal and external Organization Units
have been combined into one table (S_ORG_EXT).
The new S_PARTY table is the primary table in the Party and Single Person model and is the base table
for all Party BusComps. It is a single entity to store organization units (both external and internal),
positions, access groups (new), user list (new), household (new), contacts, and employees. The single
party model is implemented with Siebel extension tables - S_USER, S_EMPLOYEE, S_CONTACT,
S_ORG_EXT, S_POSTN, and S_BU. Each non-person party directly or indirectly has person members –
employees, contacts. The data model was converted to the single party design, but the BusComps, view
modes, and views were kept the same as in Siebel 6.x release.
The S_PARTY_PER table contains relationships between parties such as Access Groups, Accounts and
Organizations, Positions, Households, Persons, and User Lists to support visibility. It replaces the
S_EMP_POSTN, which stored Employees and Positions relationships.
The S_PARTY_REL table contains ad-hoc, informational relationship between parties. For example,,
ABC Company’s accounting firm is Acme LLP; Joe Jones influences Mike Harris. This table replaces the
S_ORG_REL, S_CONTACT_REL, and S_PER_ORG_UNIT tables. This will not be a forced move for
7. Little (if any) relationships use this table in standard Siebel configuration for 7 (horizontal)
There are three pre-built hierarchies within Siebel 7 which are implemented via the S_PARTY_RPT_REL
table – Positional, Organizational, and Access Group. (Note that these hierarchies are 1 to many.) This is
a system table that contains denormalized party relationships. Not all party relationships are
denormalized here, only visibility hierarchy relationships. The Positional denormalization is the one to
enable Manager’s visibility. But this denormalized relationship was formally stored in
S_POSTN_RPT_REL, which this new table replaces. This table will be used if customers configure a
Sub-Org view which shows data for a users Organization and all of those Organizations below it in the
hierarchy. The Access Group hierarchy is also denormalized into this table, allowing visibility to Access
Groups above their in the hierarchy, rather than below. S_PARTY.PAR_PARTY_ID is used to create
these hierarchies, for example, Access Group-to-Access Group, Position-to-Position, and Organization-to-
Organization. These denormalized relationships enable the Manager and Sub-Organization View modes.
The new Single Party Design has made several tables obsolete. The S_EMPLOYEE table is obsolete as its
functionality was merged into the S_CONTACT table. The S_ORG_INT table is obsolete, as its
functionality has been merged into S_ORG_EXT. S_EMP_POSTN has been replaced by
S_PARTY_PER.
There are several other new tables in the data model supporting the consolidation of S_EMPLOYEE with
S_CONTACT and of S_ORG_INT with S_ORG_EXT. The S_USER table stores Siebel User
information. The S_EMP_PER stores attributes for Brand-Owner Employees and Partner Users who are

considered agents of the Brand-Owner, supporting sales and service activities on behalf of the Brand-
Owner. The S_BU table stores Organization information.
S_PARTY_CTGRY is an intersection table between the catalogs and Siebel Parties. It will be used to
control access across parties to the categories.
In addition, the catalogs and categories still maintain the hieratical relationship. With that, anyone that
have access to the parent catalog, can also access all catalogues defined under it.
The following tables have been obsoleted in Siebel7:

• S_EMPLOYEE
• S_EMPLOYEE_ATT
• S_ORG_INT
• S_ORG_INT_ATT
• S_POSTN_RPT_REL
14
Shared Categories Party
Catalog
Catalog Access Business
Unit
Org
Category Category - Account
Access - Corporation
- Govt Agency
- etc.
Master Data
Person
Literature Category - Employee
Product Item - Contact
Price List
Solution
etc.
Customer Data
Org Party Relationsh
Opty Team Role
Quote - Person role
Order Owner - Employment
SrvReq Team - etc.
etc.
Contact
Team

Single Party data model
§ Single entity to store organizations, positions, user lists, contacts, employees, households etc.
§ Implemented with Siebel extension tables
§ Each party has person members: employees, contacts
§ Party relationship to relate any two parties
Party Relationship Denorm Party Party Member

(new) Relationships (new)
S_PARTY_REL (new) S_PARTY_PER
S_PARTY_RPT_REL
PER
Party
Position Bus. Unit Household Users (new) Organi

S_POSTN (new) (new) S_USER S_ORG
S_BU S_ORG_GROUP
Party
User List Access Group (new) S_PARTY
Party Type (LOV)

Additional Enhancements
Three new view visibility types have been added to the Siebel architecture in Siebel 7 to facilitate the
access control enhancements –
• Personal – Records owned by user (employee or contact) or team of users

• Sales Rep – Records owned by position or team of positions
• Manager – Records owned by position or it's subordinate positions, or
Records owned by employee or it's subordinate employee in the position hierarchy
• Organization – Records owned by organization
• Sub-Organization (New in 7) – Records owned by organization or it's subordinate organization
• Group (New in 7) – Records owned by the group or it's parent groups
This visibility type shows all the Catalogs and Categories a user has access to by being a member
of one or more Access Groups that are associated to them. The user can then navigate down the
hierarchy to view the master data items in each category. The InfoCenter view, which is an
explorer view of Catalogs and Categories, uses the Group visibility type.
• Catalog (New in 7) – Records assigned to the catalog owned by the group or it's parent groups
Another enhancement is the ability to restrict visibility to data in child applets of Detail Views. This can
be achieved by setting the visibility mode on the Link within Tools. The benefits of this can be illustrated
in the eChannel application. If Organization visibility is set on the Account and Opportunity Link,
Partners with access to the Account>Opportunities view will only see Opportunities which belong to their
Organization.

Remote Users
Access Control exists and provides functionality and content not only for connected clients but also for
mobile clients as well. The Siebel remote and dock object architecture has been extended to facilitate the
Access Group functionality. This means that whatever visibility one set up will also be seen in the mobile
client.
Siebel Remote Routing Rule Types

• Employee – Records owned by employee or team of employees.
• Employee Manager – Records owned by employee or it's subordinate employee in the position
hierarchy.
• Position – Records owned by position or team of positions.
• Position Manager – Records owned by position or it's subordinate positions.
• Organization – Records owned by organization.
• Node – Records owned by the mobile client or any of its child mobile clients.
• Catalog (New in 7) – Records in a catalog that is associated to an Access Group of which one is
a member. An Access Group can have Organizations, Accounts, Positions, User Lists and
Access Groups.
Refer to Siebel Bookshelf for complete documentation on dock objects and visibility.

Upgrade Issues
The upgrade process does handle most of the work. Employee records are automatically moved into the
S_CONTACT, S_USER, and S_EMP_PER tables and the data is mapped to the appropriate places (for
example, Last Name to Last Name). Internal Organization and division records are moved into the
S_ORG_INT and S_BU tables appropriately. The upgrade creates all the S_PARTY records necessary
and associates them to the correct extension table record. All of the standard and custom joins to
S_EMPLOYEE are moved to S_CONTACT, S_USER, or S_EMP_PER appropriately. The same is done
for standard and custom joins to S_ORG_INT. The business components are also automatically changed
to have S_PARTY as their primary table.
Although the upgrade handles most of the work, it does NOT automatically add a customer’s extension
columns that have been added to S_EMPLOYEE or S_ORG_INT or the associated EIM and IF tables.
But the upgrade will produce a report of the columns, which were not applied, and need to be analyzed. If
the customer decides there is not a close match to a column on the S_CONTACT, S_ORG_EXT or related
tables, they need to manually extend the appropriate table and move that data through an EIM process or
some other supported method.
The upgrade to Siebel 7 will handle the following:

• Movement of data from S_EMPLOYEE to S_CONTACT, S_USER, S_EMP_PER (standard
columns)
• Movement of data from S_ORG_INT to S_ORG_EXT, S_BU (standard columns)
• Creation of the Party table records (for each previous contact, position, employee, account)
• Joins to S_EMPLOYEE changed to S_CONTACT, S_USER, S_EMP_PER (standard and
custom)
• Joins to S_ORG_INT changed to S_ORG_EXT (standard and custom)
• Business components changed to point to S_PARTY as Primary Table (Employee, Contact,
Position, Account, etc...)
The upgrade to Siebel 7 will NOT handle the following:

• Application of extension columns that were created for S_EMPLOYEE and S_ORG_INT (or
associated EIM and IF tables)
• Movement of data from extension columns that were created for S_EMPLOYEE and
S_ORG_INT
Note: To assist in migrating the columns and data to the new tables, Siebel applications will generate a
report during the upgrade that lists those fields on business components that reference columns which will
need to be moved to facilitate this process. It is important to note that Siebel applications may have added
new columns which provide functionality that in prior versions required extension columns. Customers
should analyze the new data model to see if that the new Siebel 7 standard column can be used in place of
their custom extension columns before creating all of the custom extensions from their previous
repository.

Multi-Org vs. Access Group
In Siebel 7, Siebel Systems, Inc. has implemented and enhanced two major Access Control
Mechanisms:
• Extended Multi-Org to apply to selected Customer Data objects
• Created Access Group Access Control Mechanism that for now, applies to Master Data objects
only, but would be extended to cover Customer Data going forward
It is important to understand the difference between Multi-Org and Access Control before making any
decision of migration at all. In describing the difference, this document will use the framework
provided in the Siebel Access Group Access Control Tech Note Refer to the document for details.
Readers familiar with the basic Siebel data model and concepts of Multi Org and Access Group can
refer to the following table for a comparison between the two. For detailed introduction to these two
mechanisms please refer to the afore-mentioned Tech Note.
Table 1. Difference between Multi-Org and Access Group
Data that’s Persons and Access Applicable to

How to Use Access Groups that are Control these Siebel
Options Controlled granted access Policy and business
to data usage components
Multi-Org § Data item § -Organization level § Used where data § Master Data (6.x):
and record person grouping partition is along SmartScript, Product,
level control § -No hierarchical the line of Literature, Price List,
structure between organizations Catalog, Responsibility
§ In Siebel 7,
organizations § Administered § Customer Data (7
both Master assumed. For through associating only): Account, Partner,
Data and part example,, an multiple Competitor, Order,
of Customer organization whose organizations with Quote, Cost List and
Data parent organization a piece of data Rate List, Opportunity
(including can access a certain record and do it for
Opportunity, record cannot access each data record
Account and the record unless it is one wants to multi-
Partner and explicitly in the org access control
Competitor, Multi-Org field of
that record
Order, Quote,
Cost List and
Rate List) are
multi-org
enabled
Access Group § Category § Any random § Can be flexibly § Master Data (7 only):
and Catalog grouping of person or used in any way Product, Literature,
level control persons; theoretically user wants Competitor, Auction
can deal with Items, Resolution,

§ In Siebel 7, can deal with § Administered Items, Resolution,
only selected everything from an through associating Solution, Decision
Master Data individual person, a access groups Issues, Events, Training
(Product, random group of (which indirectly § Customer Data:
Literature, persons, a group of contains persons) currently being planned
Competitor, persons holding the with categories and for future releases and
Auction Item, same positions, a catalog (which not available out of box
Event, group of person directly or for 7
Training, belong to the same indirectly contains
Solution, organization, a group data items and
Resolution, of contacts who records)
etc.) are being belong to the same
Access Group household or the
enabled; same account, etc.
Access Group § Hierarchical
access control structure is assumed.
mechanism For example,, a
cannot be used person who belongs
with Customer (indirectly) to an
Data access group, whose
parent access group
have access to a
certain category, will
be able to have
access to this
category
21
Planning and Design
It is very important for customers implementing Access Control to put the proper time and effort into
the analysis, planning, and design of their Access Control model. Proper design and implementation
of these structures is very important to the usability and functionality of the application.
The differences between the two visibility control mechanisms, Multi-Org and Access Group, was
described in the section “Multi-Org vs. Access Group”. Because of these differences, Multi Org and
Access Group are used differently in Siebel applications. This section will discuss two processes to
decide when and where to use each mechanism. These two processes are designed respectively for
customers that have deployed Multi-Org and are now in the process of migrating to Siebel 7, and
customers who have not deployed Multi-Org but are thinking of doing so or are planning
implementing Siebel 7.
The two decision processes are heavily centered on the “Data” component in access control. Before
going into the two processes however, customers should first go through the following relatively
simply exercise centered on the “Users” component in access control. Often, this exercise can help
make a quick decision as to which mechanism to use:
Study the users one wants to grant access to data to:

- Is there any hierarchical structure inherent among the users?
§ If so, does the user want to leverage the inheritance feature when it comes to access
control? (for example,, if one grants a group of users who are parent to another
group of users access to a certain piece of data one wants the children group also to
be able to access the data)
§ If so, Access Group would most likely better meet their requirement than Multi Org
§ If not, go through the two processes (graphical flow chart) described later
§ If not, go to the following point.
- Is “Organization” the best business object to group the users?
§ If so, go through the two processes (graphical flow chart) described later
§ If not (for example,, when users are working with families, “Household”, a new
business object introduced in Siebel 7 is the appropriate entity to use instead of
“Organization”, which typically has a specific meaning that’s not appropriate in
this context), then Access Group would most likely better meet their requirement
than Multi Org
All Siebel applications customers either on 6.x Siebel products or ready to purchase Siebel 7 fall into
the following three categories:
§ They have deployed neither Access Group (not available until 7) nor Multi-Org
§ They have multi-org enabled selected Master Data objects (in 6.x no Customer Data objects were
multi-org enabled), or
§ Customers currently using Multi-Org who are remaining with Multi-Org and not implementing
Access Control Access Group

Customers currently using Multi-Org who are implementing Access
Control
For customers that have deployed multi-org and are in the process of analyzing the various Siebel access
control options when migrating to 7, everything is the same as for customers who have not deployed either
access control mechanism, except that these customers need to worry about the Master Data they have
Multi Org enabled. What should they do about it? It is hard to find a cookie-cutter answer that fits all. The
multi-org deployment situation varies wildly from customer to customer and there is no one answer that
fits all. Using the following flow chart, this document attempts to provide some general guidelines for
customer’s reference:
Figure 1: Flowchart for Customers Having Deployed Multi Org
Start (for
Customers who
Have Deployed
Multi Org
Already)
Step 1: Is Your Step 2: Follow the

Access Control Decision in the Instruction for
New Data (that You have not
Context of Already Multi-Orged Customers who have End
Multi-Orged)
Data or on New Data that's not not Deployed Multi
Multi-Orged Yet? Org Yet
Data that You Already Have Multi-Orged

(these Data can Only be Selected Master Data
and some Administrative Data)
Step 4: Is there any Step 5.1: Building

Step 3: Is the Inherent Hierarchy Step 5.2: Use
Yes up Hierarchical
Data Volume Large? Relationship Yes Access Group to
Catalog/Category
between the Data? Replace Multi-Org
Data Structures
No
No (Recommended)
Yes
Step 6: Is it Highly Likely that

the Data Volume will Grow Siignificantly, Step 8: Keep the
sooner or later? No No (Not Desirable; to be Adopted Current Multi-Org
only when Resource is Limited) Structure
Unchanged
No
Step 7: Did You Multi-Org

enabled the Data for the Purpose of No (Not Highly Recommended if You Have enough Resource)
Data Partitioning?
Yes
Explanation to Figure 1:
Step 1: Is the Access Control Decision in the Context of Already Multi-Org’ed Data or on New Data
that's not Multi-Org’ed Yet? For all new access control projects (not on data already Multi-Org’ed) under

plan, it is strongly recommended that customers use the first flowchart (scenario 1)to think about which
access control mechanism to use.
Step 2: Follow the Instruction for Customers who have not Deployed Multi Org Yet. This step is self-
explanatory.
Step 3: Is the Data Volume Large? Refer back to the description to Step 4 in flow chart 1 explanation for
more.
Step 4: Is there any Inherent Hierarchy Relationship between the Data? Refer back to the description to
Step 3 in flow chart 1 explanation for more.
Step 5.1 and 2: Building up Hierarchical Catalog and Category Data Structures; How to convert Multi-
Org and Multi-Org enabled data into Access Group and Access Group controlled data. In real life,
customers deploy Multi-Org in very different contexts, and when they plan to migrate the data to Access
Group, the Access Group hierarchies they want to build can vary wildly, depending on their specific
requirements. But no matter how differently they build their Access Group hierarchies and structure their
data, the following steps need to be performed:
• Build Access Group hierarchies – need to adapt the existing organizations into these hierarchies
• Build hierarchical data structure. When doing this bear in mind the Access Groups that have
been created earlier.
• Create the association between Access Group and Category and Catalog.
For customers considering following these steps to move Multi-Org enabled data, to be Access Group
controlled, it should be noted that it might (but not necessarily have to) be a long and hard process to
build up the catalog and category hierarchical structure of data and to build one or multiple Access Group
hierarchies. Before these data and user hierarchies are built, Multi Org still plays an important role in
controlling access to data by users.
Alternatively, the standard configuration provides some upgrade scripts which automatically migrate
Multi Org access controlled data into Access Group access controlled. Note that the purpose of the script
is only to guarantee uninterrupted upgrade and not to produce the most appropriate catalog and category
and access group structure. It is highly recommended that when (if) customers do choose to use the script,
they use it only for the transition period – between when they upgrade their system to 7 and when they
follow the above steps to build up their own catalog and category, access group structure. Please see
Appendix B for a description of the migration script algorithm.
Step 6: Is it Highly Likely that the Data Volume will grow significantly, sooner or later? This is a critical
question because although currently the data volume may not be large, it may grow over time and soon the
system administrators will run into problems associated with huge volume of data. In case where the
volume is likely to grow significantly, following the logic in Step 3, it is recommended customers to use
Access Group.
Step 7: Did the Multi-Org enable the Data for the Purpose of Data Partitioning? For a description of
“Data Partition” refer to Appendix A. When one reaches this step in the flow chart, it means that he’s not
dealing with a large amount of data, and the data is unlikely to grow in volume either. In this case, if the
data is Multi-Org’ed for the sake of data partition, which is what multi org is created for, it is
recommended that customer stick with it. If not, the general recommendation is that customers should use
Access Group to replace Multi Org, although not doing so due to limited resource is also acceptable.
Step 8: Keep the Current Multi-Org Structure Unchanged. Multi Org and Access Group would co-exist in
7 and beyond. All the hard work customers have invested into building up the multi-org structure and
24
enabling Master Data is not wasted if they choose not to apply Access Group to the Multi-Org enabled
data.
25
Customers not currently using Multi-Org who are implementing Access
Control
Figure 2: Flowchart for Customers Not Having Deployed Multi Org
Start (for
Customers who
Have not
Deployed Multi
Org Yet
Step 2: Are you Doing it Now

Step 1: Which Data
Customer Data (Typically Small Doing it Now or in the (Access Group
Type are you Trying to Use Multi Org
in Volume and no Hierarchy) near Future (6 -12 doesn't Apply to
Control Access to?
months) Customer Data in 7.0)
No
Doing it in the Near Future
Master Data (Typically Large in Volume
and have Inherent Hierarchy)
Step 3: Is there any Inherent

Step 4: Is the
Hierarchical Relationship
No Data Volume
between the Data you want to
Large?
Access Control?
Yes Yes
Step 5: Categorize No
Data into Step 6: Categorize
hierarch(ies) Data (not
necessarily into
hierarchy)
Use Access Group
End
Explanation to Figure 2:
Step 1: Which Data Type is one trying to Control Access to? A limitation of Access Group in 7 is
that it only applies to Master Data. One uses this step to differentiate between Customer Data and
Master Data. Note however, that it is on the plan that Customer Data will be Access Group enabled
in the next major release.
Step 2: Is one doing it Now or in the near Future (6 -12 months)? Since Access Group is not an
option for Customer Data, if the customer is planning to deploy access control to Customer Data
now, they have no choice but use Multi Org. If however, they are planning to do it in 6-12 months
from now, as observed is the case with many customers, Access Group would be applied to
Customer Data and therefore they might want to decide differently.

Step 3: Is there any Inherent Hierarchical Relationship between the Data one wants to Access
Control? It is recommended that customers use Access Group for both hierarchical Customer Data
and hierarchical Master Data (for an explanation to “Hierarchical” data see Appendix A); although
it should be pointed out that more often than not Customer Data doesn’t have an inherent
hierarchical structure. Multi-Org is not appropriate for controlling hierarchical structured data.
Step 4: Is the Data Volume Large? In the case of there being no hierarchical structure within the
data, a critical question to ask is the data volume. Huge data volume typically translates into
administration nightmare if Multi-Org is used. In the case of one major Siebel applications client for
example,, they have up to 1 million data records for a certain business object – there’s not
necessarily a strong hierarchical structure within the data. When using Multi Org to control access
to the data however, system administrators need to go through each one of the million records and
manually associate one or multiple organizations with each one of them. Further, even if some of the
records area associated with the same set of organizations, the “set of organizations” cannot be re-
used. In this case, Access Group offers a much more scalable solution than Multi Org, to be
described in Step 6.
Step 5: Categorize Data into hierarchies. This step is straight forward – when there’s hierarchical
structure within the data, one should map this hierarchy into the data structure (using categories and
catalogs) design.
Step 6: Categorize Data (not necessarily into hierarchy). Following Step 4 – if there’s no
hierarchical structure within data but the data volume is huge, one can use category and catalog to
categorize data that are common to certain business units (e.g., organizations) together. Because
Access Groups are re-usable, simply associating various Access Groups with categories will do the
access control, rather than having system administrators go through every single data record and
associate multiple organizations with each one of them.
27
Customers currently using Multi-Org who are remaining with Multi-Org
and not implementing Access Control Access Group
Customers who have implemented Multi-Org and have decided not to implement Access Control will
have to make some adjustments to the standard Siebel 7 configuration. The visibility properties of several
objects have been changed to take advantage of the Access Group functionality. The visibility of those
objects will have to be reset to organization visibility settings for those customers that are not implanting
Access Group and are staying with the Multi-Org functionality. Business component “Popup Visibility
Type” property has been changed from Organization to catalogue visibility to support the Access Group
functionality and the applet query mode has been put in query mode.
Tasks for configuring Multi-Org:
1. Find all business components currently set with popup visibility mode of “Catalog”. A query can
easily be run in Siebel Tools to bring this list back. The following is a list from Standard Siebel
applications (more important business components are bolded):
• Admin Decision Issue

• Banter Resolution Item
• Competitor
• Component Product
• Contact Decision Issue
• Decision Issue
• ERM Internal News Category
• Internal Product
• Recommended Product
• Related Issue
• SR Resolution Item
• Sales Tool
• Solution
The popup visibility mode for these business components should be changed from catalog to
organization.
2. Find all popup applets currently in query mode:
• Asset Mgmt - Internal Product Pick Applet

• CPG Internal Product Pick Applet
• Catalog Admin Category Assoc Applet - Competitor
• Catalog Admin Category Assoc Applet - Decision Issue
• Catalog Admin Category Assoc Applet - Literature
• Catalog Admin Category Assoc Applet - Product
• Catalog Admin Category Assoc Applet - Resolution Item
• Catalog Admin Category Assoc Applet - Solution
• Catalog Admin Category Assoc Applet - Training
• Catalog Admin Category Assoc Applet - eEvents Event
• FS Parts & Tools Pick Applet
• FS Use Plan Products Pick Applet

• Incentive Compensation Product Pick Applet
• Internal Product Pick Applet (eSales)
• Issue Assoc Applet
• Opportunity Management - Product Number Pick Applet
• Opportunity Management - Product Pick Applet
• Order Entry - Line Item Product Pick Applet
• Product Number Pick Applet
• Product Pick Applet
• Product Pick Applet - No Clear
• Product Pick Applet - No Insert
• SR Internal Product Pick Applet
• Sales Tool Pick Applet
• Service Locator List Applet
• Training Course Product Pick Applet
Change property "Auto Query Mode" of the pick applets to NULL from “New Query” or “None”.
3. Make sure that any views with visibility applet type of “Catalog” are accurate.
• Change the [Service Solution List View (SCW)] view from catalogue visibility to
organization visibility. This view had sales rep visibility in Siebel 6, which kind of doesn't
make sense. It probably should have had Org visibility.
4. The other thing worth documenting is that there is no flat list of literature in eChannel Partner
Portal in Siebel 7. The screen and view still exist in Tools, but they are not active in the
application. If customers want to use the view they will have to make it active in Tools.
29
Administration and Setup
Administrators will create catalogs, categories, and build the category hierarchy. Of course, the design of
these should be well thought-out. Once these are created, data items can be related to the categories.
Different types of master data can be related to the same category. A customer could create a Catalog
called ‘Software’and a category for ‘Customer Relationship Management Software’. The administrator
will associate all of the Product, Literature, Courses, and other master data items that should be related to
this category.
Administrators will also build the Access Groups and hierarchies. Of course, the design of these should
be well thought-out. User Lists can also be created and Employees and Contacts associated to them.
Persons will also be associated to Positions, Accounts, and Organizations. Then Positions, Accounts,
Organizations, Households, and User Lists can be associated to the Access Groups.
Access Control Setup Procedures

Step 1: Plan Hierarchy Design
• Carefully analyze all business requirements and how data and parties should be segregated
Step 2: Build a Data Hierarchy
• Create Catalog
• Create Category levels below Catalog
• Associate Data items (Products, Literature, Solution, Auction Items, Decision Issues, etc) to
Categories
Step 3: Build an Access Group Hierarchy
• Create Positions, User Lists, Accounts, Organizations
• Associate Persons to Positions, User Lists, Accounts
• Create Access Group Hierarchy
• Associate Organizations, User Lists, Accounts to Access Group(s)
Step 4: Associate Access Groups with Categories and Catalog(s)
Refer to the “Authentication and Access Control Administration Guide” for complete documentation on
administration procedures.
Note however, using Catalogs and Categories to build up a Data Hierarchy is SEPARATE from Access
Group Access – it is a way to organize data, and applying Access Group is just one way to manipulate the
organized data, and Access Group Access happens to only apply to Categorized data for 7.
Create the categories and catalogs, access groups, and hierarchies based on individual category and
catalog and access groups in a test environment once the Access Control strategy and design have been
created. The design should be thoroughly tested to make sure that the access control policies work in the
way that they are intended.
Content Management's publish features will be used to move the Access Control model including
catalogs, categories, groups from one environment to another – test to staging or test to production.
Content Center (aka content management) supports publishing data from one environment to another
based on EAI. It is much more that simply changing a status flag, which has specific limitations included
inability to update or delete an in process piece of content without affecting the application.
The basic idea is I build content (e.g. InfoCenter catalog or product catalog) in a staging environment and
test it. When I am happy with it, I publish it to my live environment, which makes all the necessary

inserts, updates, and deletes to bring the production environment up to date. The publishing is based on
EAI, so the only requirement is that there be an integration object for the content one is publishing. In
this example, these have already been built for catalogs and categories, the only piece missing would be
the access group hierarchy. This should be maintained within the production environment. It is not
recommended to publishing the party to access group part of the equation since the party data is too
dynamic (for example, in the time it takes to test and publish there could be hundreds of new parties).
Then one can publish the rules (access groups to categories).
31
Assignment Manager
Assignment Manager SQL has been converted to use new single party tables. So joins to S_PARTY and
it queries from new tables (e.g. S_EMP_PER vs. S_EMPLOYEE). The admin UI is now enabled for
HTML thin client, but the functionality is still the same. The Assignment Manager Algorithm for Siebel
7 is same as Siebel 6.x
Assignment Manager does not support Access Groups in 7, because Access Groups only work with master
data and do not work with transactional data. They are planning to enable it for the next major release.
When this is done, Assignment Manager will be able to assign items to Access Groups.

Terminology
Term Definition
Access Control Refers to all mechanisms to control visibility within Siebel eBusiness
applications
Party Single entity to store Account, Contact, Organization, Division, Employee,
Group and Position (one table, with several extension tables to store entity-
specific columns)
Access Group Mechanism to bundle Party entities
Category Used to organize data into a hierarchical structure
Catalog Highest level of category
Master Data Data that is relatively static (for example, Products, Literature,Solution and
FAQ, Resolution, Decision Issue, Training, Auction Item, Asset)
Customer Data Data that is typically dynamic, transactional (for example, Accounts,
Contacts, Activities, Service Requests, Opportunities)
User List Contains Siebel Persons as its members
They are created on an ad hoc basis, not restricted to organizations the
persons belong to or the positions they hold

Appendix A
This section discusses “Hierarchical structure” within data and access controlling data for the purpose of
“Data Partition.”
• “Hierarchical Data”: often, some inherent hierarchical structure exists within certain data type.
Example: IBM has hundreds of thousands of products. All IBM products can be divided into
hardware products and software products; software products can be further segmented into
mainframe software, web software, etc. Within web software, there’s the IBM Websphere
application server, IBM Secureway directory, IBM eCommerce application products, etc. Within
IBM Secureway directory, there’s directory server and directory SDK. Within the directory
server, there are different versions and for different languages. As walking through this series of
description, it is essentially navigating through a hierarchical structure.
Because of the hierarchical structure existing within the data, when it comes to access control, users need
to have a mechanism that considers the hierarchy nature of the data – for example,, users can control the
visibility to different branches and at different levels, and carries certain inheritance rules (such as – if I
have access to a parent level, than I can see all the children levels, etc.)
• “Data Partition”: many times, there’s no or hardly strong hierarchical structure within data.
Example: Siebel System, Inc. has many customers across a lot of industries. Every customer in
and of itself is an account and a separate entity, for example,, users do not often see one account
as being the “parent” account of another. In many cases, there’s not a strong hierarchical
structure amongst accounts. Note however, a very important nature of this type of data is that
there’s a need to “partition” the data. Following the example: for Siebel sales representatives
working on different accounts, representative A working on account A should see Account B’s
information to avoid conflict of interest; the same applies to representative B working on Account
B, who shouldn’t be allowed to see Account A’s information.
From an access control perspective, this is to say, there’s a need to “partition” data into different sections
– certain data are intended for certain eyes while others for other eyes. That is what is called “data
partition”. Bear in mind that there is no hierarchical structure among the data.
• “Hierarchical” type of data and “Data Partition” apply to both Customer Data and Master Data;
often, however, users have observed from our customer deployment, that Master Data tends to be
more “Hierarchical” and Customer Data more “Data Partition”.

Tech 312

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tech 312

Încărcat de

Drepturi de autor:

Formate disponibile

The Leader in eBusiness

12/21/01 Siebel Systems, Inc. Confidential and subject to change

TABLE OF CONTENTS ......................................................................................................................3

ABOUT THIS DOCUMENT................................................................................................................4

WHAT IS ACCESS CONTROL?.........................................................................................................5

ADDITIONAL ENHANCEMENTS ...................................................................................................17

REMOTE USERS ...............................................................................................................................18

MULTI-ORG VS. ACCESS GROUP.................................................................................................20

PLANNING AND DESIGN ................................................................................................................22

ADMINISTRATION AND SETUP ....................................................................................................30

OUTSTANDING .....................................................................ERROR! BOOKMARK NOT DEFINED.

What is Access Control?

In Siebel 2001, many more objects have been Multi-Org enabled.

Multi-Org Enabled Objects

Single-Org Enabled Objects

An Application of Access Group Access Control

The solution must meet the following requirements:

Figure 1. Reseller Community and Reseller Resources Catalog Logic

Figure 2. Reseller Resources Access Control

Service FAQs (Svc FAQ 1, Svc FAQ 2, ...)

Product Training (Class 1, Class 2, ...)

Product Documentation (WP 1, WP 2,...)

Marketing FAQs (Mktg FAQ 1, Mktg FAQ

Decision issues (DI 1, DI 2, ...)

Sales Training (Class 3, Class 4,...)

Competitive Briefs (CB 1, CB 2,… )

Marketing Training (Class 5, Class 6,… )

Apply the following principles to construct this structure:

12/21/01 Siebel Systems, Inc. Confidential and subject to change

To implement this structure

12/21/01 Siebel Systems, Inc. Confidential and subject to change

The following tables have been obsoleted in Siebel7:

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Party Relationship Denorm Party Party Member

Position Bus. Unit Household Users (new) Organi

Party Type (LOV)

12/21/01 Siebel Systems, Inc. Confidential and subject to change

• Personal – Records owned by user (employee or contact) or team of users

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Siebel Remote Routing Rule Types

12/21/01 Siebel Systems, Inc. Confidential and subject to change

The upgrade to Siebel 7 will handle the following:

The upgrade to Siebel 7 will NOT handle the following:

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Table 1. Difference between Multi-Org and Access Group

Data that’s Persons and Access Applicable to

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Study the users one wants to grant access to data to:

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Figure 1: Flowchart for Customers Having Deployed Multi Org

Step 1: Is Your Step 2: Follow the

Data that You Already Have Multi-Orged

Step 4: Is there any Step 5.1: Building

Step 6: Is it Highly Likely that

Step 7: Did You Multi-Org

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Figure 2: Flowchart for Customers Not Having Deployed Multi Org

Step 2: Are you Doing it Now

Step 3: Is there any Inherent

Use Access Group

12/21/01 Siebel Systems, Inc. Confidential and subject to change

Tasks for configuring Multi-Org:

• Admin Decision Issue

2. Find all popup applets currently in query mode: