| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2015 E24814-01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Siebel Security Guide Siebel Innovation Pack 2015 E24814-01 |
|
Previous |
Next |
View PDF |
Two main strategies are available for controlling access to data in Siebel Business Applications:
Multiple-organization access control. This strategy limits data access to only those organizations that have a need to see the information. Organizational access control can be implemented across internal or external organizations. This strategy can be applied to transaction data, master data, and other referential data. For more information, see "About Organization Access Control".
Access-group access to catalogued data. This strategy can be implemented with all party types. It is designed to reduce access control administration by associating hierarchical groups of users with similarly organized data. This strategy can be applied to master data only. For more information, see "About Access-Group Access Control".
|
Caution: Configuring changes in access control for a Siebel application can be a complex task. Such changes can have significant implications for the entire application and can involve significant risks. For these reasons, it is recommended that you contact Oracle's Professional Services for a design review before undertaking any major modifications to access control in your Siebel application. Contact your Oracle sales representative to request assistance from Oracle's Professional Services. |
For additional information on planning for access control, see the following topics:
As part of implementing an access control strategy for your application, you must define your company's structure, outside partner relationships, and so on. You also define the types of data and objects that people need to access and work with to perform their job functions. How you define the structure of your business environment directly impacts how access control applies to your users.
This topic provides some background information about business environment structure. If your enterprise is large and complex, you can accurately reflect its structure as you set up your Siebel Business Applications. You can build multilevel hierarchies of organizations, divisions, and positions. You build a hierarchy by associating positions, for example, with other positions through parent-child relationships.
Defining your business environment structure involves setting up the elements shown in Table 9-3.
Table 9-3 Elements of Business Environment Structure
| Element | Parent-Child | Description |
|---|---|---|
|
Divisions |
Y |
Subunits of your company's (or partner company's) organizations. Used to set default currencies. Not used to control visibility of data. |
|
Organizations |
Y |
The major parts or entities that make up your company (or your partner companies). Used to control visibility of data. See "About Organization Access Control". |
|
Positions |
Y |
Control the data set (records) to which a user has access. See "About Position Access Control". |
|
Responsibilities |
N |
Control the views to which a user has access. |
|
Employees |
N |
Individual users in your company and in partner companies who have access to your company's data. |
You can set up divisions, organizations, positions, responsibilities, and employees in any order. You can also associate these types of records with one another in a variety of ways. For example, to link a responsibility and an employee, you can associate the employee with the responsibility from the responsibility record, or you can associate the responsibility with the employee from the employee record.
|
Note: Because organizations are based on divisions, it is recommended that you create your hierarchy of divisions first, and then determine which of these divisions to designate as organizations. |
|
Caution: Changing your company structure, such as positions and divisions, can cause Siebel Remote components (Transaction Router) to reevaluate access control for all objects related to the objects that have changed. This can result in diminished performance. For more information, see Siebel Remote and Replication Manager Administration Guide. |
Using organizations provides the following benefits:
It allows your company to partition itself into logical groups, and then display information appropriate to each of those groups.
It provides the ability to limit visibility (access) to data based on the organization to which positions are assigned.
It affects both customer data (accounts, opportunities, service requests, and so on) and master data (price lists, literature, and so on).
It allows you to assign skills to organizations, which allows Assignment Manager to make assignments based on organization.
It allows you to set up multitenancy for call centers. For more information, see Siebel CTI Administration Guide.
If your Siebel application is already deployed and you do not need to change your users' visibility (access), your company might not need more organizations. Some circumstances where your company could benefit from multiple organizations are as follows:
Internal business units. If you have a small number of distinct internal business units, you might want to use organizations to support specific versions of a limited number of data entities such as products and price lists.
Complex global enterprise. If you have a full-scale global enterprise that encompasses multiple internal and external businesses, each of which is made up of multiple business units, your company benefits from implementing organizations. In this circumstance, some data can be available only to some business units, while other information can be shared at the corporate level.
Internal and external units. If your company shares data with external partner companies, you can set up each of these companies as an organization. You can make fewer views available to these external organizations than to your internal organizations. You can also configure the employee list so that it shows only employees who belong to the user's organization.
Different rules for business units. If you would like to make different Siebel Assignment Manager or Siebel Workflow rules apply to different parts of your company, then your company benefits from implementing organizations. For example, a company might want some Assignment Manager rules to apply to a telesales organization and other rules to apply to customers of its Web site.
Web-enabled enterprise. If you have customers who log in through a Web site, you can set up a customer organization to control their access to views and data. If you have channel partners who log in through a Web site, you set up channel partner organizations to control their access.
For more information on using organizations with Siebel customer and partner applications, see Siebel Partner Relationship Management Administration Guide.
Related Topic
This topic and those that follow explain the common tasks for defining a company structure in your Siebel application. These include tasks for defining divisions, organizations, responsibilities, and positions.
Divisions belong to organizations and have no direct effect on visibility. Divisions help you to group positions, to record addresses, and to maintain default currencies. User reporting structures are defined by their parent positions, but their country of operation and currency are defined by their division. To implement Siebel Business Applications, you must set up at least one division.
An organization can contain multiple divisions, but a given division can only be part of one organization. Organizations can be arranged into a hierarchy of parent organizations and suborganizations. You can also promote a division to an organization. Multiple divisions can be arranged in a multilevel hierarchy by assigning some divisions as the parents of others.
You can assign positions to a division. When you associate employees with those positions, the employees become associated with the division.
Related Topics
"About Planning for Organizations"
Organizations are designed to represent the broadest divisions of your company. An organization controls the data access of the employees that are assigned to it. Organizations can be internal, or they can be external (in the case of Siebel Partner Relationship Manager).
The organization associated with the employee's active position determines visibility for the employee. Conversely, the organizations that are associated to the employee, such as using the Employee Organization field in the Employee business component, determine visibility to the employee record for this employee.
Setting up organizations is an optional step in your implementation. If you are upgrading from a previous version of your Siebel application, all the data is automatically assigned to one default organization. With one organization, there is no impact on visibility and data access. However, if you want to divide your company into multiple structural units, you can create multiple organizations.
You might want to delegate administration of users to organizations that access only their users. To do this, you must configure the appropriate views using Siebel Tools. For more information on configuring views, see Configuring Siebel Business Applications.
The following are best practices for working with organizations:
Merging organizations is not recommended. Because many business objects are configured for multiple-organization access control, you might disrupt these relationships to a significant extent and get unexpected results.
It is recommended that you do not change the name of the default organization, which is Default Organization. This record is seed data that is referenced in many places. If your company decides to change the default organization name, the name must be unique from any other organization or division name. References to Default Organization in other locations must also be changed.
For example, if you are using Siebel Assignment Manager, you might have to rename references in assignment objects to the new name for the default organization. For more information, see Siebel Assignment Manager Administration Guide and Configuring Siebel Business Applications.
|
Note: You cannot delete organization records. Business components throughout your Siebel application refer to organization records. Deleting an organization could cause invalid references on transaction records. This could lead to unexpected negative results, such as valid data not appearing in the user interface. |
Related Topics
"About Planning for Divisions"
"About Planning for Positions"
"About Planning for Responsibilities"
A position represents a specific job slot within your company. As you define your company structure, define specific positions with each level in the hierarchy of divisions. Positions determine which records users have access to. You must be logged on to a server database to add positions.
An employee must have a position to create and use accounts, opportunities, contacts, and other customer data objects in your Siebel application.
Each position typically has only one associated employee. In some circumstances such as job-sharing situations, a position can have multiple associated employees. One employee can be associated with multiple positions. There can be only one primary employee for a position, but an employee can be primary for more than one position.
There is a drawback to having multiple employees associated with a position. Because a position can have only one primary employee, only the primary employee is visible in the Employee field. If you search for an employee in a positions list, you might not find relevant position records in which the employee is not primary for the position.
Only the primary employee for a position appears in the Account Team, Opportunity Sales Team, and Contact Access lists. However, all the employees in that position can access the My Accounts, My Opportunities, and My Contacts views.
A position can be associated with only one organization. If you want an employee to have visibility to multiple organizations, you must create a position for each organization and assign that employee to each position. The employee can then see one organization's data at a time by changing positions.
Your Siebel application allows users to change their position to another position to which they have already been given access by the administrator. A user can change positions while logged in by choosing Tools, User Preferences, and then Change Position, selecting a different position in the list, and clicking the Change Position button. For instance, a sales representative can change position to a sales executive and have access to the same views as the previous position, but gain visibility to another organization's data.
Positions can be set up in a multilevel hierarchy, which allows for manager access control. The parent position gains visibility to all the sets of data visible to the individual child positions. (Usually, the data is displayed only where the child position is the primary on the team or record.)
You cannot make a position obsolete by setting the End Date. This field records only the end date for the current employee associated with the position. It does not make the position obsolete after that date has passed.
If you rename a position, check these areas in your Siebel application to make sure the name change is reflected correctly:
Assignment rules, if you have used these positions in assignment rules. For more information, see Siebel Assignment Manager Administration Guide.
Workflow processes, if you have used these positions in workflow processes. For more information, see Siebel Business Process Framework: Workflow Guide.
Enterprise Integration Manager (EIM), if you are referring to these positions in EIM import SQL scripts. For more information, see Siebel Enterprise Integration Manager Administration Guide.
The Position field of the Employees view.
Related Topics
"About Planning for Divisions"
Responsibilities determine which views users have access to. For example, the System Administrator responsibility allows access to all views. Defining responsibilities lets you limit user access to views, and therefore to your Siebel application's information and functions. You must assign responsibilities to all users. Without a responsibility, a user cannot use the Siebel application, because that user cannot access any views.
You can also assign tab layouts and tasks to responsibilities. For more information, see "Managing Tab Layouts Through Responsibilities" and "Managing Tasks Through Responsibilities".
To define a responsibility, you must specify which views are available to that responsibility. It is recommended that you use the responsibilities that are provided as seed data, where applicable. These can be copied and then customized. Then define any additional responsibilities you require that correspond to the major job functions in your organization.
For example, you might use or create responsibilities for the marketing administrator, the sales manager, and sales representatives. The sales representative responsibility might have access to all views except those reserved for sales management, marketing administration, and applications administration. The sales manager responsibility might have access to the same views as the sales representative, plus the sales manager views, and so on.
As appropriate, you can specify that a view is read-only for a given responsibility.
|
Note: You cannot modify or delete the seed responsibilities. For instance, you cannot change the Siebel administrator responsibility. You can copy the seed responsibilities and modify the copies. |
When you are defining responsibilities, consider the following issues:
Grant access to the System Preferences view to only a selected group of administrators; do not give end users access to the System Preferences view. System preferences control many things throughout the Siebel system, including some server logic and processing for Siebel Remote and Siebel Assignment Manager.
Do not add Administration views to responsibilities associated with end users. Likewise, limit access to the Master Forecasts, Mobile Web Clients, Responsibilities, Views, and Territories views. The work performed with these views has far-reaching implications for the entire application.
Where users require access to data presented in a view, but do not need to create or modify data, specify that the view is read-only for this responsibility. (If any one responsibility for a user is associated with a view that is not marked with the Read Only View flag, the view will not be read-only for this user, regardless of how the flag is set for any other responsibility.)
You might want to hide access to license keys by deleting the license key-related views from a user's responsibility. For more information about license keys, see Siebel Applications Administration Guide.
If you add the Internal Division view to a user's responsibility, all organizations in the Organizational picklist are displayed. By default, only the organization the user belongs to appears in this picklist.
If you log into the application through the normal Siebel Web Client, you can add new views to responsibilities in the Administration - Application, Responsibilities view.
Related Topics
"About Planning for Divisions"
