Access to views and data in Siebel applications is controlled through a combination of responsibilities, views, positions, organizations, and record ownership. Responsibilities determine the set of views a user has access to. Views can then control access to specific records using mechanisms like personal access control, position-based access control, and organization-based access control. Different view types like "My View" and "All View" accommodate different user access needs. Overall, responsibilities control view access while positions, organizations, and record ownership control data access within those views in a flexible, independent manner.
Module Overview
Welcome to Visibility
This module focuses on view and data level Access Control. This module deals with the subject of Access Control.
The intent of this module is to introduce the subject of Access Control, distinguish between two types of Access Control (view level and data level), and identify the relationships between views, users, and responsibilities. It also explores the different Access Control mechanisms used to restrict user access to data in Siebel eBusiness Applications. This module emphasizes the fact that access to views is independent of access to data. It also explores the different view types used to accommodate the needs of different users. The module will then explain what is that determines the Access Control behavior of business components, and what is that determines the records that list views display for business components with Access Control mechanisms
After completing this module you should be able to:
Describe Access Control for Siebel eBusiness Applications
Discuss Access Control and Views Describe the difference between view level Access Control and data level Access Control
Identify the access control mechanisms used to restrict access to views in Siebel eBusiness Applications
Describe the relationships between views, users, and responsibilities
Identify the independent relationship between view access and data access
Identify the different view types used to accommodate the Access Control needs of different users
Determine the access control mechanism for a business component
Configure views to control access to data based
So what is visibility, Visibility simply put is what views and data an employee sees when they login to a
Siebel Application. As a developer, you can control visibility in two ways:
Responsibility controls what views are available when the employee logs in to the Siebel Application
And Position control what records from the business components are displayed in the view.
Based on these two factors, a user’s record access visibility in a particular view may be any of the
following visibility types:
Sales Team Visibility - provides the user with access to records whose sales team or contact access list contains his or her position.
Personal Visibility - provides the user with access to records in which his or her position or logon ID is designated as the owner.
Manager Visibility - provides the user with access to records that have a sales team in which a subordinate is designated as the primary position (if the business component uses Sales Team visibility). Alternatively, it provides access to records with an owner ID belonging to a subordinate (if the business component uses owner-based Personal visibility). The reporting relationship may be direct or indirect (such as the subordinate of a subordinate).
Organizational visibility - provides the user with access to records within a given organization.
All visibility - provides the user with access to all records, except for those with a missing or invalid primary position in the sales team.
One thing that we have to establish before we begin our discussion on access control is that different users need to access different information.
Within a typical organization, you're dealing with internal people and external people. We have people like CFO, and the CFO of a company typically does a lot of things, one of which is forecasting. So in order to do that, a CFO needs to access a lot of financial information in the company.
Whereas working in the same company are other people like field sales representatives. Instead of having to access all those high-level financial data, a lot of times they have to have access to customer data like opportunities. And then at the same time, there are also people like call center agents, who have to access a lot of service requests and be assigned activities.
Besides these internal users that we're talking about, a typical organization also deals with a lot of external parties like customers and your channel partners. While your customers may have to place orders and be able to access the orders that they have placed, your channel partners, like the distribution channel partners, have to have access a bunch of other data items like opportunities and service requests.
So essentially, here we are talking about different users have different needs to access different information.
Now, this is to capture what we have just said in the previous slide.
There are basically two types of users.
Internal users. So typically these are users that are working in the enterprise and that have access to data such as accounts and opportunities. And again, even if there are internal users, different internal users may have different needs to access different data.
External users, as we have said on the previous slide, like your customers. These are typically the users who do not work for the company. External users have access to data such as orders. And finally, a special case of the external users are the combination of both internal and external – these users are called partners.
Partners are a special set of users. They are treated as external users because they are not working in the organization that you're working in, but they are treated as internal users because they're working in an organization that deals very closely with your organization. So partners have access to data such as certain accounts, products, and price lists and orders.
Now, after having covered users, we're going to talk about access control.
So essentially what access control is, is something that restricts what is seen in the application according to, number one, view access. So basically when a user opens up a Siebel application, what jumps out are a bunch of screens and what we call views. And it is actually the responsibilities that are associated with the users that control which views and which screens a user can see.
At another level within these so-called views and screens, there are a lot of data items. And the data items are actually typically made up of data, what we call customer data, and master data. Customer data is constantly changing data like opportunities, quotes, service requests, and accounts. They're dynamic. People log them. People track them. Information inside of these data items change from time to time. And the visibility obtained is through record ownership, positions, and organizations. So we use things like organization and a position, which are associated with users and record ownership, which is typically who has created the record to control who can see these customer data items.
Another type of data, as contrast to customer data, is master data. Master data is typically less changing in its nature. So things like literature, auction items, solutions, resolutions, products, and so on - they stay constant typically throughout their life. And the visibility to these master data are controlled using Access Groups. And besides the data level access control and the view level access control, we have application access.
Application access is typically what we call security and authentication. So basically people authenticate themselves either through the database authentication or through the LDAP directory authentication with a user name and password to obtain access.
Now, we talked about access control from an administration point of view, i.e., there are different levels of access control that we can enforce at the application level, at the view and screen level, and at the data level.
Let's take a quick look from an end user point of view. Basically this slide gives you a visual impression as to how access control is enforced. At the very top level, we have the logic view of the things that users see. Suppose you are a user. You bring up a Siebel application. You click it open, and you see a bunch of screens and views.
In the middle in the two clouds, basically, it is how we control what you see, which screens you see, which views you see, and which records you see. In the first cloud you see there's an organization. And that is mapped into real-life organizations. Within each organization, a user typically has one or multiple responsibilities. All of these responsibilities are associated with one or multiple views or one or multiple screens, and an employee is associated with one or multiple responsibilities. Therefore, an employee gets access to one or multiple views or screens through their responsibilities.
Besides responsibilities, another thing than an employee typically has is a position. So think about position as being pretty much one-to-one mapping to an employee. The position stays much more constant than an employee. While an employee can join and quit the company, positions typically stays with the company.
So we have created this notion of positions. And through positions, we associate employees with so-called sales teams, and we associate these sales teams to the records. We also associate employees directly to records in the case of ownership.
So basically through responsibilities and positions, as illustrated in the middle bar, we enable an employee or a typical user to be able to access different views, different screens, and different records.
And at the database level, by the way, it is worth mentioning that we also have encryption of the data so that whatever data an employee has access to, it's going to be encrypted before it's being sent into the database, and it's going to be decrypted before it is read out of the database. That's another level of access control that we have enforced.
Now, let's go a little bit deeper into responsibility.
View access is controlled by responsibility. Responsibility is the set of views associated with a particular function. Let's give an example here.
A call center representative can be a responsibility. Another responsibility is a call center administrator. A call center administrator's responsibility is different from a representative in that a call center administrator typically administers a lot of things like starting and deactivating workflow products, activating access control or deactivating access control. Whereas call center representatives typically receives customer calls, creates opportunities, creates contacts information in the database and so forth.
So administrators typically deal with administration work, representatives deal more with customer-related business objects like activities and opportunities and contacts. Therefore, we have created different responsibilities to be assigned to different people so that they can access different views and screens.
Now let’s discuss adding views to a responsibility. Before we continue, it is important to note that different responsibilities can share a common set of views.
Typically, two different responsibilities would not have the identical set of views in common, however it is quite possible that they can. In the example above, you can see that both the Call Center Manager and the Universal Agent share a common set of views however it would be quite possible to add a view to just the Call Center Manager responsibility and not the Universal Agent responsibility. What this would mean is that each different responsibility would have access to see different views.
Once you have assigned views to responsibilities, you will need to assign users to the responsibilities so that when a particular user signs in, the responsibility that they are associated with will determine what views they have access to.
It is important to note that each user can be assigned to multiple responsibilities, because they can have multiple job roles and will require access to different sets of views based on those job roles. The example above depicts this. The user in the screen shots is assigned to both the call center manager responsibility and the universal agent responsibility.
If you have assigned a user multiple responsibilities, what they will have access to is a union of both of the responsibilities in which they are assigned.
The screenshot above is a typical site map that a user may see. If a user has been assigned multiple responsibilities, the site map will show the combination of all the views the user will have access to for all of their assigned responsibilities.
So just to recap on what we have discussed so far.
A responsibility determines the set of views for which a user has access.
A view is associated to one or more responsibilities and a user is assigned to one or more responsibilities. Therefore when a user logs in, they will see a union of all the views that are associated with the responsibility for which they are assigned.
Now before we move onto our next topic, we would like to emphasize that users will not have access to any views that are not associated with the user’s assigned responsibilities. In other words, if a particular user is assigned a responsibility but the ABC Contact List View is not part of that responsibility, then that user will not have access to see a reference to that view and therefore would not be able to access that view.
A user can navigate to a view in one of three ways;
By selecting a view through the site map
Through the show drop-down list
Through the detail tabs and none of these will point to a view that a user does not have access to
Access to customer data can be restricted using one of these access control mechanisms.
Personal access control - If individual data can be associated with a user’s Person record in the database, then you can restrict access to the data to that person.
If individual data can be associated with a position, then you can apply Position-based access control to the data position.
If individual data can be associated with an organization, you can apply Organization-based access control to the data
These types of access control will be discussed in the following slides.
Typically, you can implement Personal access control when data has a creator or a person is assigned to the data, usually as the owner.
For example:
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 Product Defects, My Service Requests, and Personal Address Book. 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-based access control. For example, the My Opportunities view applies position-based access control.
A position represents a specific job slot within your company. As you define your company structure, you should define specific positions with each level in the hierarchy of divisions.
Positions determine which records users have access to. Positions are usually unique to every employee, that way if an employee ever leaves the company or gets promoted, the data that employee is responsible for can easily be transitioned by assigning that specific position to another employee.
A position represents a specific job slot within a company. Specific positions exist with each level in the hierarchy of a company structure.
Position-based access control uses positions to determine which records users have access to. Positions provide an appropriate basis for access control in many scenarios because a position in a company structure is typically more stable than the individual’s assignment to the position.
The next five slides present details on the relationship between users and positions. This is followed by an explanation of how position-based access control is used to restrict user access to data.
Typically, each position has only one associated employee.
However, in some circumstances, such as job-sharing situations, a position may have multiple associated employees.
You can associate a single position to individual data.
The previous slide presented the fact that there can be multiple employees associated with a single position.
When there are multiple employees assigned to a position, there is only one employee designated as the primary employee for a position. There can be only one primary employee for a position, but an employee can be primary for more than one position. Only the primary employee for a position appears in a record’s team field (discussed later in this module). However, all the employees in a position assigned to a record can access the record.
Just as a person can be assigned multiple responsibilities, an employee can be assigned multiple positions.
One employee can be associated with multiple positions if they have multiple job roles. When assigned to a position, an employee logs in as that particular position and sees records associated with only that position.
An employee can have multiple positions, but only one position is designated as the employee’s primary position. By default, employees are logged in as their primary position.
The position a user is logged in as is also referred to as the user’s active position. Changing position which will be discussed on the next slide allows users to view a different set of data.
Because users can be assigned to multiple positions, Siebel applications allow users to change position to any other position they are assigned to. Changing position provides access to the set of data associated with the new position. For example, a user might be assigned to a sales representative position and a sales manager position. If the user selects Change Position and changes from the sales representative position to the sales manager position, they could see the same set of views (determined by their responsibilities), but a different set of data within those views.
To change a users position, go to the View application menu and select User Preferences. When you navigate to the new screen, select the Change position option from the show menu and you will be taken to a screen that allows you to change your 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-based access control to the data by one or more of the following means:
Single Position access control
Team-based access control
You can associate a single position to individual data. For example, in the My Quotes view, an employee logged on in a particular position can see only the Quotes associated with that position. Some views that apply single position access control are My Forecasts and My Quotes.
The word “My” is sometimes used in the titles of views applying single position access control. However, “My” does not always imply single position access control.
We just learned that most “My” views apply personal access control. For example, the My Activities view.
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 may include internal and partner positions. A team can include internal and partner positions and all users associated with the positions on the team have access to the record.
Views that allow team access control have specific fields that allow for the assignment of multiple positions to a record. This slide identifies some of common views that apply Team access control with corresponding display names for the Team fields. The display names for fields representing position teams vary with the view in which they appear but the access control mechanism are all the same.
The My Opportunities view has Sales Team as the display name. The My Account view has Account Team as the display name. My Contacts has Contact Team as the display name.
The display name for team based access may differ from view to view, but the underlying access control mechanism still provides the same functionality.
Every team that is defined has one position designated as Primary. The position that is automatically designated as the primary is the position of the user who creates the record. The Primary position on a team has privileges that are not shared by the other positions on a team.
For example, the primary position can merge and delete records where other user do not have this ability. The primary position can also forecast an opportunity or designate another position as primary. Keep in mind that the primary position on a team can also be changed by an administrator or through Assignment Manager. Assignment Manager is a server process and is a topic that is discussed at a high level in another module of the course.
This slide provides a definition of an organization within the context of Access Control. Organizations are designed to represent the broadest divisions of a company. An organization exists for the purpose of providing a container in which positions can be associated with data. An organization controls the data access of the employees that are assigned to it. They can be internal, or they can be external (partners).
Organizations allow your Siebel application, using a common application configuration and data model, to be subdivided into multiple virtual configurations. Each configuration supports the unique data sets, business rules, and processes of a number of business organizations. Those organizations can selectively share data between groups or individuals, both along the organizational hierarchy and between unrelated groups.
Organization-based visibility can restrict access to records for part of your company by dividing the organization intro division, departments, or different business units. It can also restrict access to records for a partner company that assists you in your business or to an external company or someone that purchases your products.
Unlike Personal and Position-based access control mechanisms, which provide access control at an individual user level, Organization-Based access Control mechanisms provide access control at the business organization level. Organization level access control can be applied to records meaning that record access is limited to the organization to which a user’s positions are assigned.
Some views allow individual data to be associated with an organization. A user is associated with one organization at any given time, the organization to which the user’s active position belongs. The user can see data that is associated with the user’s active organization. For example, a user logs in as a certain position. That position is the user’s active position. That position is associated with an organization. That organization is the user’s active organization. The user can see all the data associated with the user’s active organization.
Similar to Position-based access control, when individual data can be associated with an organization, you can apply Organization-based access control to the data by a Single Organization or a Multiple Organization.
A Single Organization means that you can associate a Single Organization with individual data and Multiple Organization means that you can associate multiple organizations with individual data.
Lets look at a couple of examples.
Single Organization access control is the mechanism by which a single organization is assigned to a record. Some views allow only a single organization to be assigned to a record. In the configuration for this example, My Contacts is an example of a view that applies single Single Organization Control. All users associated with the organization of Siebel Americas, will have access to this particular record.
Multiple Organization access control is the mechanism by which multiple organization can be assigned to a record. This is similar to having multiple positions assigned to a record in the form of a team. Some views allow multiple organization to be assigned to a record.
All users associated with the assigned organizations have access to the record. In this example, the My Opportunities is view that applies multiple organization access control. This means, Siebel EMEA and Siebel Americas both have access to this record of data so every position associated to either Siebel EMEA or Siebel Americas has visibility to this record.
This slide provides a quick review of the access control mechanisms presented in this module.
Personal access control limits access to records to the records a user has created or to which a user has been assigned.
Position-based access control limits access to records to those users based upon their position within an organization.
Organization-based access control is where record access is limited to the organization to which a users position is assigned.
A new concept is introduced in the last bullet point - More than one access control mechanism can be applied to an individual record.
For example, access to an opportunity record can be restricted by positions on a sales team and multiple organizations. All users associated with the positions and the organizations have access to the opportunity record.
This slide ties together the key concepts we have presented so far. What you need to understand is that access to views is controlled by a user’s assigned responsibilities, and access to data is controlled by access control mechanisms.
For example, two users can have access to the same set of views, determined by their responsibilities, but have access to a different set of data within those views, determined by a user’s ID, position, or organization.
Different types are designed to accommodate different users and their needs. Some additional views have been created to accommodate managers, administrators, and executives who have data access needs that go beyond access control rules, these are the special access views. The special access vies are “My Team’s View”, “All View” and “All Across Organization View”
Each of the view types listed in the above slide will be covered in detail over the next few slides.
This slide addresses how the mode of a view is specified. The view mode is configured by setting the Visibility Applet and Visibility Applet Type properties in the view.
The Visibility Applet property identifies the driving business component for limiting the data. Setting the Visibility Applet Type determines the specific access control mechanism used for that specific view. So, for example, an All View will probably use the Visibility Applet Type of All.
The slide also mentions another important fact about setting the two properties in a view. Setting these two properties causes the view to be considered a Context view and that is what causes the view to appear in the show drop-down list). Non-context views typically appear as view tabs and have null values for both the Visibility Applet Property and Visibility Applet Type.
The My View displays records for which a user has direct access based upon the users position.
Example of view that typically use this view mode include the My Opportunities or My Accounts View. To further detail an example, the My Accounts View displays all account records that I am on the sales team. Let’s look at how to configure this type of view.
Views that are meant to display only records for which the user’s position is on the team with access (these views are most often labeled My View) are configured in the following way:
Firstly you must create a business component view mode definition by navigating to the Business Component object definition and selecting the business component for which the view exists.
You need to then navigate to the Business Component View Mode definition and create a new record. The Business Component View Mode that you will need to create for the My View is Sales Rep. Sales Rep view mode is also used for views where the business component has single position ownership (for example, Quotes). Some of the important properties in this definition are:
The Owner Type property which declares the Access Control mechanism. The drop-down list shows the five possible values. The Owner Type property is the party type, with one exception, that is used to determine whether a user is associated with a record. The allowable owner types are:
Person. Access control can be based on the user’s Person record.
Position. Access control can be based on the position of the user.
Organization. Access control can be based on the organization of the user, as determined by the organization to which the user’s current position belongs.
Group. Access control can be based on membership in access groups that have access to particular catalogs and categories. And,
Catalog Category. Catalog Category is the only owner type that is not a party type. Access can be restricted to all of the data in all of the categories across catalogs to which the user has access. This data includes data in public categories and data in private categories to which the user’s access groups have access. The user sees a flat (uncategorized) list of data.
The Visibility property specifies whether the parent business component is individual or team based. A value in one of either Visibility Field or Visibility MVField is required. The value in this field is compared with the corresponding value for the user, as specified in Owner Type, to determine whether the user is associated with a record. If they are associated, the user gets access to the record. A value in the Visibility field indicates that there is only one party associated with this business component when using this view mode.
The Visibility MVField property has the same purpose as Visibility Field, except a value in this field indicates that there can be more than one party associated with this business component when using this view mode.
The Visibility MVLink property is required if there is a value in Visibility MVField. This field specifies which of the business component's multi value links should be used to determine the value in the MVField for this record. Links establish a parent/child relationship between business components, often by specifying an intersection table (in the case of a many-to-many relationship). This multivalue link's Destination Link property indicates which link ultimately defines this relationship.
If you would like detail on the other properties used for the business component view mode, refer to the Authentication and Access Control Administration Guide.
A business component’s view modes determine the allowable access control mechanisms that can be applied to the business component in any view. When a view is based on a particular business component, the view must use one of the view modes specified for the business component.
When you have a business component view mode that corresponds to the My View that you want to create, you can update the views properties to set the the Visibility Applet Type to Sales Rep and set the Visibility Applet property, to indicate the applet in the view that will drive the visibility (it is actually the business component that is referenced by the applet that will govern the visibility).
Views that are meant to display only records for which the user directly owns ( most often labeled My View or on occasion My Personal) are configured in the same way as described for My View with a single difference.
The Visibility Applet Type must be set to personal. In addition the Visibility Applet is set to indicate the applet in view that will drive the visibility (actually it is the business component that is referenced by the applet that will govern the visibility). Remember that you will need a corresponding BusComp view mode definition. This view mode will need to have an owner type of Person to correspond to this view.
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. If the user’s position has no subordinate positions, then the user sees no records, not even his or her own records. So typically a management position will use the My Team’s View.
My Teams views can be configured in the same way as described for both My View and Personal View. Here the visibility applet type must be set to manager and the the Visibility Applet is set to indicate the applet in view that will drive the visibility.
The corresponding business component view mode definition must have its name property set to Sales Rep with the owner type set to Position or Person.
“All” is frequently in the titles 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.
“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 may be a person, a position, a valid primary sales team position, or an organization, depending on the view modes that are available for the business component.
All View views can be configured in the same way as described for all of the other view types.
Here the visibility applet type must be set to All and the the Visibility Applet is set to indicate the applet in view that will drive the visibility. However, in this case since the view will display all the records (at least those with team/users assigned), there is no need to check the access control mechanism for the business component. Therefore there is no corresponding entry in the Bus Component view mode for an All view.
All Across Organizations views are used by executives to gain access to data across all organizations. Again, only records with a valid owner are displayed. Some examples are All Accounts Across Organizations and All Opportunities Across Organizations views.
Again, as with all the other view modes, the All Across Organizations view can be configured by setting the visibility applet type Organization and the the Visibility Applet to indicate the applet in view that will drive the visibility.
This view mode looks for a Business Component View Mode with a name of Organization.
Finally, Administration views are used by administrators to view all records in the database, even those records without a valid owner.
For example, initially, a list of accounts or opportunities imported into the database will not have any positions or organizations assigned. Consequently, users who depend on Access Control mechanisms for access to data will not have access to these records.
However, administrators will need access to this data. The Account Administration view, Opportunity Administration view, and Product Administration view are examples of Admin mode views.
This view is configured by setting The Admin Mode Flag to True.
After completing this module you should be able to:
Describe Access Control for Siebel eBusiness Applications
Discuss Access Control and Views Describe the difference between view level Access Control and data level Access Control
Identify the access control mechanisms used to restrict access to views in Siebel eBusiness Applications
Describe the relationships between views, users, and responsibilities
Identify the independent relationship between view access and data access
Identify the different view types used to accommodate the Access Control needs of different users
Determine the access control mechanism for a business component
Configure views to control access to data based