| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2017, Rev. A E24814-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2017, Rev. A E24814-01 |
|
Previous |
Next |
View PDF |
The major access control mechanisms include the following, which are described in the topics that follow:
Personal access control. For details, see "About Personal Access Control".
Position access control. This includes single-position, team, and manager access control. For details, see:
Organization access control. This includes single-organization, multiple-organization, and suborganization access control. For details, see:
All access control. For details, see "About All Access Control".
Access-group access control. For details, see "About Access-Group Access Control".
If individual data can be associated with a user's Person record in the database, then you can restrict access to that data to that person only. Typically, you can implement personal access control when data has a creator or a person is assigned to the data, usually as the owner. The following are some examples:
In the My Service Requests view, a Web site visitor can only see the service requests he or she has created.
In the My Expense Reports view, an employee can see only the expense reports the employee has submitted for reimbursement.
In the My Activities view, a user can see only the activities the user owns.
Some views that apply personal access control are My Activities, My Personal Contacts, My Change Requests, and My Service Requests. The words My and My Personal are frequently in the titles of views that apply personal access control. However, My does not always imply personal access control. Some My views apply position or organization access control. For example, the My Opportunities view applies position access control.
Related Topic
A position is a job title in a division of an internal or partner organization. A position hierarchy represents reporting relationships among positions. Positions provide an appropriate basis for access control in many scenarios, because a position in an organization is typically more stable than the individual's assignment to the position.
Customer data and some types of referential data can be associated with one or more positions. If individual data can be associated with a position, then you can apply position access control to the data by one or more of the following means:
Single-position access control. You can associate a single position to individual data records. For details, see "About Single-Position Access Control".
Team access control. You can associate multiple positions, in the form of a team, to individual data. For details, see "About Team (Multiple-Position) Access Control".
Manager access control. You can grant access concurrently to data associated with a position and data associated with subordinate positions in a reporting hierarchy. For details, see "About Manager Access Control".
An employee or partner user can be associated with one or more positions, of which only one can be the active position at a given time. All types of position access control for an employee or partner user are determined by the active position.
One of the user's positions is designated as the primary position. When a user logs in, the primary position is the active position. To make a different position the active position, one of the following must happen:
An employee must designate another position as the active position, from the User Preferences screen.
A partner user must designate another position as the primary position, and then log in again.
You can configure an agent who uses Siebel CTI to automatically change positions based on the data provided for an incoming call.
For information about Siebel CTI and related modules, and about setting up agents, see Siebel CTI Administration Guide.
Related Topic
You can associate a single position to individual data. For example, in the My Quotes view, an employee logged in using a particular position can see only the quotes associated with that position. Another view that applies single-position access control is My Forecasts.
The word My is frequently in the titles of views applying single-position access control. However, My does not always imply single-position access control. Some My views apply personal, organization, or team access control. For example, the My Activities view applies personal access control.
A business component's view modes determine whether single-position access control can be applied in a view that is based on the business component. To have single-position access control available, a business component must have a view mode (usually Sales Rep) of owner type Position with an entry in the Visibility Field column (instead of the Visibility MVField column). For information about business component view modes, see "Viewing Business Component View Modes". For information about implementing access control in a view, see "Listing View Access Control Properties".
Related Topic
You can associate multiple positions, in the form of a team, to individual data. For example, in the My Opportunities view, an internal employee or partner with a particular active position can see all the opportunities for which that position is included in the opportunity's sales team. A team can include internal and partner positions.
The display names for fields representing position teams vary with the view in which they appear. Some common views that apply team access control follow, with the display names for the field representing the team:
The My Opportunities view has a Sales Team field.
The My Accounts view has an Account Team field.
The My Contacts view has a Contact Team field.
The My Projects view has an Access List field.
Although the field for the team can contain multiple positions, only one name is displayed without drilling down. In a view that uses team access control, for example My Projects, the name of the active login is displayed. Other views, such as those using organization access control, can also have a field for the team. In these other views, the name of the login that occupies the primary position is displayed.
The word My is frequently in the titles of views applying team access control. However, My does not always imply team access control. Some My views apply personal, organization, or single-position access control. For example, the My Activities view applies personal access control.
A business component's view modes determine whether team access control can be applied in a view that is based on the business component. To have team access control available, a business component must have a view mode (usually Sales Rep) of owner type Position with entries in the Visibility MVField and Visibility MVLink columns (instead of the Visibility Field column). One of a team's members is designated as the primary member. The primary member is a factor in manager access control, but not in team access control.
If a business component is configured for team access control, any new record added for that type of component follows this rule: the user who created the record is added to the record's team and is set to be the primary. For information about business component view modes, see "Viewing Business Component View Modes". For information about implementing access control in a view, see "Listing View Access Control Properties".
Related Topic
You can indirectly associate a position with data associated with subordinate positions in a reporting hierarchy. For example, in the My Team's Opportunities view, an employee with a particular active position can see opportunities associated with that position and opportunities associated with subordinate positions.
Manager-subordinate relationships are determined from a position hierarchy. One position hierarchy is included as seed data when you install your Siebel application. You can specify one parent position for a position, which represents that the position is a direct report to the parent. The parent of an internal position can be in the same division or a different division. For example, a sales manager in the Sales division can report to a sales vice president in the Corporate division.
In a view using manager access control, an employee or partner user has access to data according to the behavior outlined in the following topics.
If a view uses manager access control, and if the business component on which the view is based uses position access control, then the following behavior applies:
If the business component on which the view is based uses single-position access control, then the user sees data associated directly with the user's active position or with subordinate positions.
If the business component on which the view is based uses team access control, then the user sees data for which the user's active position is on the team or any subordinate position that is the primary member on the team. This is the standard behavior, known as primary manager visibility.
A business component using team access control can be configured to allow the user to see data for all subordinate positions, regardless of whether they are the primary position for a record. This is known as nonprimary manager visibility.
To configure nonprimary manager visibility, define a user property called Manager List Mode for the business component and set it to Team (rather than the default value of Primary). For more information about the Manager List Mode user property, see Siebel Developer's Reference.
|
Caution: Configuring nonprimary manager visibility to support mobile users requires changes to docking visibility rules. Customers who require this functionality must engage Oracle's Advanced Customer Services. Contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance. |
|
Note: The value of the Visibility Applet Type field determines the access control properties that apply to a view. However, if a more restrictive value is specified for the Visibility Applet Type field for another view that is based on the same business component, then the restrictions of this visibility type are applied to both views. For example, if two views are based on the same business component, and if Manager visibility is selected for one view and Sales Rep Visibility is selected for the other view, then the restrictions of the Sales Rep Visibility type are also applied to the user's active position or team positions on the view that has implemented Manager access control. As a result, the user does not have access to data associated with subordinates' positions. |
If a view uses manager access control, and if the business component on which the view is based uses personal access control, then the behavior is as follows:
For single-owner access control, the user sees data associated directly with the user's active position or with subordinate positions.
For multiple-owner access control, the user sees data for which the user's active position is on the team, or any subordinate position that is the primary member of the team.
Views that apply manager access control generally contain the phrase My Team's in the title, such as My Team's Accounts. (In some cases, the word My is omitted.) There are no business component view modes specific to manager access control. Manager access control is set at the view level. It requires that the business component on which the view is based has a view mode with owner type Position or Person.
Related Topics
When individual data can be associated with an organization, you can apply organization access control to the data by one or more of the following means:
Single-organization access control. You can associate a single organization with individual data. For details, see "About Single-Organization and Multiple-Organization Access Control".
Multiple-organization access control. You can associate multiple organizations with individual data. For details, see "About Single-Organization and Multiple-Organization Access Control".
Suborganization access control. You can grant access concurrently to data associated with an organization and data associated with subordinate organizations in the organizational hierarchy. For details, see "About Suborganization Access Control".
|
Note: Siebel Assignment Manager is also organization-enabled; that is, assignment rules can use organization as a criterion. |
A user is associated with one organization at any given time, the organization to which the user's active position belongs. For information about changing the active position of an employee or a partner user, see "About Position Access Control".
A contact user is indirectly associated with an organization through the proxy employee specified for a Siebel customer application. For information about proxy employees and access control, see the following topics:
Depending on the type of data, you can associate one or more organizations to individual data. The user can see data that is associated with the user's active organization. For example, in the All Service Requests view, a user can see all the service requests associated with the user's active organization.
For data that can be associated with multiple organizations, one of the organizations is designated as the primary organization. The primary organization is a factor in suborganization access control, but not in multiple-organization access control.
Table 9-2 lists data on which you can apply organization access control and indicates, for some of the most commonly used Siebel objects, whether a single organization, or multiple organizations, can be associated with the data.
Table 9-2 Data Enabled for Organization Access Control
| Object Type | Object | Relationship |
|---|---|---|
|
Customer data |
Account |
Multiple |
|
Competitor |
Multiple |
|
|
Contact |
Multiple |
|
|
Forecast Series |
Multiple |
|
|
Household |
Multiple |
|
|
Marketing Event/Activity |
Multiple |
|
|
Opportunity |
Multiple |
|
|
Order |
Multiple |
|
|
Partner |
Multiple |
|
|
Product Defect |
Multiple |
|
|
Project |
Multiple |
|
|
Quote |
Multiple |
|
|
Service Request |
Multiple |
|
|
User List |
Multiple |
|
|
Referential data (includes master data) |
SmartScript |
Multiple |
|
Literature |
Multiple |
|
|
Price List |
Multiple |
|
|
Cost List/Rate List |
Multiple |
|
|
Period |
Single |
|
|
Product |
Multiple |
|
|
Catalog |
Not Applicable (catalogs use access-group access control) |
|
|
Administrative data |
Employee |
Multiple |
|
Division |
Single |
|
|
List of Values Type |
Multiple |
|
|
List of Values |
Single |
|
|
Position |
Single |
|
|
Responsibility |
Multiple |
All (but not All across) is frequently in the title of views applying single- or multiple-organization access control. For example, the All Contacts view applies single-organization access control, and the All Product Defects view applies multiple-organization access control. However, All does not always imply single- or multiple-organization access control. Some All views apply All access control. For example, the All Service Requests view applies All access control.
A business component's view modes determine whether single-organization or multiple-organization access control can be applied in a view that is based on the business component.
To have single-organization access control available, a business component must have a view mode (typically Organization) of owner type Organization with an entry in the Visibility Field column (instead of the Visibility MVField column).
To have multiple-organization access control available, a business component must have a view mode (typically Organization) of owner type Organization with entries in the Visibility MVField and Visibility MVLink columns (instead of the Visibility Field column).
For information about All access control, see "About All Access Control". For information about business component view modes, see "Viewing Business Component View Modes".
Related Topic
Suborganization access control, based on hierarchical organizations, is analogous to manager access control, which is based on hierarchical positions. For any organization in the organizational hierarchy, you can grant access to data associated with subordinate organizations. This access control mechanism is designed to provide rollup views of data.
For example, a director of a continental sales organization can see the data rolled up from subordinate regional sales organizations. A vice-president in the corporate sales organization can then see rollups of the continental sales organizations and the regional sales organizations. Subordinate relationships are determined from the organizational hierarchy, as an administrator can view by navigating to Administration - Group, and then Organizations.
The organizational hierarchy is included as seed data when you install your Siebel application. Within the organizational hierarchy, you can create branches for both internal and partner organizational structures. You can specify one parent organization for an organization.
In a view using suborganization access control, the user has access to the following data:
If the business component on which the view is based uses single-organization access control, the user sees data associated directly with the user's active organization or with a descendant organization.
If the business component on which the view is based uses multiple-organization access control, then the user sees data for which the user's active organization or a descendant organization is the primary organization.
The titles of default views applying suborganization access control are structured as All business component name across My Organizations, such as All Opportunities across My Organizations. There are no business component view modes specific to suborganization access control. Suborganization access control is set at the view level. It requires that the business component on which the view is based has a view mode with owner type Organization.
Related Topics
All access control provides access to all records that have a valid owner, as defined in any of the business component's view modes. The owner can be a person, a position, a valid primary position on a team, or an organization, depending on the view modes that are available for the business component.
All users with a view in their responsibilities that applies All access control see the same data in the view. A user's person or position need not be associated with the data.
All access control essentially provides a view of data across all organizations. For example, in the All Quotes across Organizations view, a user sees all the quotes that are associated with any internal or external organization in the Enterprise, for which there is a valid person, position or organization owner.
The phrases All across and All are frequently in the titles of views applying All access control. For example, the All Opportunities across Organizations and the All Service Requests views apply All access control. However, All does not always imply All access control. Some All views apply single-organization or multiple-organization access control. For example, the All Contacts view applies single-organization access control.
A separate property (Admin Mode) provides the means to see all records in a view using team access control, including those without a valid owner. Admin mode allows the administrator to modify records that otherwise no one could see. You specify Admin mode for a view in the Admin Mode Flag property.
There are no business component view modes specific to All access control. All access control is set at the view level.
Related Topics
Access groups are used to control access to master data by diverse groups of party types. An access group is a collection of any combination of positions, organizations, account, households, and user lists. Its members are instances of party types other than Person; that is, its members cannot be individual people. For example, an access group could consist of several partner organizations and user lists to which you want to grant access to a particular set of your sales tools.
A user is associated with an access group if, during the current session, the user is associated with a position, organization, account, household, or user list that is a member of the access group. Although you can add divisions to access groups, doing so has no effect on visibility. Use organizations instead.
You can create hierarchies of access groups. An access group can belong to only one access group hierarchy. That is, an access group can have only one parent access group. For example, the access group mentioned earlier might belong to a hierarchy of access groups for the purpose of granting differing levels of access to sales tools.
You can grant access groups access to catalogs and categories of master data: products, literature, solutions, resolution items, decision issues, events, training courses, and competitors. For example, branches in the access group hierarchy could be granted access to categories in a hierarchical catalog in which each category contains sales literature and decision issue items. For an illustration of an access group hierarchy (master data), see "Access Control for Data".
A category of master data can contain any combination of master data items. You can only control access to catalogs and categories of master data. You cannot control access to individual master data items using access-group access control.
When access groups are associated with a catalog or with categories in the catalog, you can apply access-group access control. You can control access to the data in one of the following ways:
Group. While in a given category, the user sees either a list of the category's first-level subcategories (child categories) to which he or she has access or all the data records in the current category, depending on the applet being used. If the user is at the catalog level, the user sees the first-level categories.
Catalog. The user sees a flat list of all the data in categories across all catalogs to which the user has access. This access control type is typically used in product picklists and other lists of products, such as a recommended product list.
Related Topics
