About Access Control

Access control is the term used to describe the set of Siebel application mechanisms that control user access to data and application functionality. As you work with this chapter, determine how the terminology and concepts presented here correspond to your company's internal terminology and structure. This chapter explains the Siebel access mechanisms, but you have to decide during the planning stage how to combine the mechanisms to meet your business and security needs.

In Siebel application terms, a screen represents a broad area of functionality, such as working on accounts. The set of screens to which a user has access is determined by the applications that your company has purchased. Each screen is represented as a tab, at the start of the window. In the following example, the Accounts screen is displayed.

Each screen contains multiple views to provide different kinds of access to the data. To the user, a view is simply a Web page. Within a view, the user might see lists of data records or forms, presenting individual or multiple records, and sometimes child records. (These lists and forms are referred to as applets in a configuration context.) Each view (or grouping of views) is represented by text in the link bar.

For example, Figure 9-1 shows the Account List View, which corresponds to the applet title My Accounts (the current visibility filter selection). Multiple view modes provide access to different views that filter the data differently. In the Account List View, the current user can view accounts owned or assigned to this user. Choosing All Accounts from the visibility filter displays the All Account List View instead, assuming the user has access to this view.

Figure 9-1 My Accounts View

To control the resources and privileges that users are entitled to once they have accessed a Siebel application and have been authenticated, Siebel CRM provides the following access-control elements:

• View-level access control. A screen is composed of views, and the collection of views to which users have access determines the application functionality available to them. Access to views is determined by responsibilities.

  Organizations are generally arranged around job functions, with employees being assigned one or more functions. In Siebel CRM, these job functions are called responsibilities. Each responsibility is associated with one or more views, which represent data and functionality needed for a job function. Each user must be assigned at least one responsibility to access the Siebel application.

  Siebel Business Applications ship with many predefined responsibilities and you can also define any additional responsibilities you require. For additional information, see "Responsibilities and Access Control".

• Record-level access control. Record-level access control is used to assign permissions to individual data items within an application so that only authenticated users who need to view particular data records have access to that information. You can control the data records that each user can see through a variety of mechanisms, including direct record ownership by a user (personal access control) or being on the same team as the record owner (team access control). The following topics examine access control further:

  • "Access Control for Parties"

  • "Access Control for Data"

• Business Components and Data Access. Within Siebel CRM, views are based on business components and must use one of the view modes specified for the business component. A business component's view mode determines the record-level access control mechanisms that can be applied to the business component in any view. Applet and view properties also determine the data available in a view. For additional information, see "About View and Data Access Control".

Figure 9-2 illustrates the Siebel access control elements. As shown in the figure, responsibilities provide access to views, and the data records visible to a user on a view are determined by the type of access control that applies to the data, the business component view mode, and view and applet visibility properties.

Figure 9-2 Siebel Business Applications Access Control Elements

Access Control for Parties

Individual people, groupings of people, and entities that represent people or groups are unified in the common notion of parties. Different party types have different access control mechanisms available.

Note: For technical information about how parties function at the data model level, see "Party Data Model".

Parties are categorized into the following party types: Person, Position, Organization, Household, User List, and Access Group. Table 9-1, "Party Types and Parties" describes the qualitative differences among different parties and identifies the applicable party type for each party.

Table 9-1 Party Types and Parties

Party	Party Type	Examples	Distinguishing Features
Person (or Contact)	Person	An employee at a customer company. An employee at a competitor's company.	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.
User	Person	A registered customer on your Web site. A self-registered partner user, that is, one who has no position.	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.
Employee	Person	An employee at your company.	An Employee is a User who is associated with a position in a division within your company.
Position	Position	A job title within your company. A job title within a partner company.	Positions 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 within a partner company is associated with a division and is associated with the partner organization to which that division belongs. A position can be associated with one division only. A position can have a parent position. It can 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.
Partner User	Person	An employee at a partner company.	A Partner User is a User who is associated with a position in a division within an external organization. Therefore, a Partner User is also an Employee, but not an internal one.
Account	Organization	A company or group of individuals with whom you do business.	An account is typically made up of contacts. An account is not a division, an internal organization, or an external organization. An account can have a parent account. It can also have child accounts. An account can be promoted to a partner organization.
Division	Organization	An organizational unit within your company such as Manufacturing or Corporate. A group of people operating within a particular country.	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 can have a parent division. It can also have child divisions. Data cannot be associated directly with a division. (Divisions that are not designated as organizations do not drive visibility.)
Organization	Organization	An organizational unit within your company, such as your European organization. Countries are not units of access control in Siebel Business Applications; use organizations to manage access control for specific groupings of countries. A partner company.	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.
Household	Household	A group of people, typically a family, who reside at the same residence. A group of purchasers who live in different residences.	Typically, a household is a group of individual consumers who are economically affiliated and share a common purchasing or service interest. A household can have any combination of contacts, users, employees, and partner users as members. An individual can belong to more than one household.
User List	User List	A support team made up of some internal employees and some partner users.	A user list is a group of people. It can have any combination of contacts, users, employees, and partner users as members. A user list cannot have a parent or children.
Access Group	Access Group	Your partner IT service providers and business-to-business customer companies that buy networking equipment. A partner community, such as the resellers of a particular sector of your product line.	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 can have a parent access group. It can also have child access groups.

Related Topic

"About Access Control"

Access Control for Data

The type of data and whether the data is categorized determines which access control mechanisms can be applied. The following groupings of data are necessary for the purpose of discussing access control:

• Customer data

  • Customer data includes contacts and transactional data such as opportunities, orders, quotes, service requests, and accounts.

  • Access is controlled at the data item level, through a mechanism such as individual record ownership or ownership by an organization.

• Master data

  • Master data includes the following referential data: products, literature, solutions, resolution items, decision issues, events, training courses, and competitors.

  • Master data can be grouped into categories of similar items, for example, hard drives. Categories can then be organized into catalogs, for example, computer hardware, which are hierarchies of categories. Access can be controlled at the catalog and category levels through access groups, which is the recommended strategy for controlling access to master data. For more information about creating catalogs, see Siebel eSales Administration Guide.

  • Master data can be associated with organizations. By associating master data with organizations, access can be controlled at the data item level. This strategy requires more administration than the access group strategy.

  
  

  Note: Divisions provide a way to logically group positions and assign currencies. Organizations provide a mechanism to control data access.

  
  

• Other data

  • Other data includes referential data that is not master data, such as price lists, cost lists, rate lists, and SmartScripts.

  • Access is controlled at the data item level.

Data Categorization for Master Data

Master data can be organized into catalogs made up of hierarchical categories. Organizing data this way serves two purposes:

• Ease of navigation. Categorized data is easier to navigate and search. For example, it is easy to find products of interest in a product catalog organized by product lines and subgroups of related products. For example: Computer Hardware, Hard Drives, and then Server Drives.

• Access control. Access to catalogs and categories of master data can be granted to collections of users. This is an efficient means to control data access in given business scenarios. For example, you can control partner users' access to your internal literature.

You can categorize master data to represent hierarchical structures, such as product catalogs, geographical categories, service entitlement levels, training subject areas, or channel partners. A catalog is a single hierarchy of categories, as illustrated in Figure 9-3.

Figure 9-3 Example Category Hierarchy

The following properties apply to catalogs and categories:

• A catalog is a collection or hierarchy of categories.

• Individual data items are contained in categories.

• A category can contain one or more types of master data.

• A category can be a node in only one catalog.

• A data item can exist in one or more categories, in one or more catalogs.

• A catalog can be public or private. If it is private, then some access control is applied at the catalog level. If it is public, then all users can see this catalog, but not necessarily categories within this catalog, depending on whether the categories are private or public.

Related Topic

"About Access Control"