One of the great advantages of Siebel as a CRM system lies in the wide variety of options it offers for countless users with different profiles to access personalized content. To achieve this, the system uses the properties with which the user has been configured, such as its Organization, Division, Position, Type of Position or LOGIN.
Customization is sometimes very complex, since it can be defined in the development phase (Siebel Tools allows you to restrict the visibility of content in Views, Applets, etc.), but it can also be implemented later by an Administrator user. I will focus on this last option to summarize some of the possibilities of filtering information for each user, and also how we can facilitate access and manipulation of it:
- Access to Views: This is the most obvious, not all users should be able to access all views of the application.
- How it is managed: Responsibilities are used. Each active user must be assigned one or more responsibilities to be able to access the application and the different views that it comprises. Each Responsibility defines for the users who own it to which views they have access, and whether this access is read-only or not.
- Where configured from: In Responsibility Administration View.
- When the changes made are applied: They should work immediately after emptying the cache and logging the user back into the application.
- Data that appears in the overviews: In addition to what has been configured in the Tools, the data accessible in each view can be filtered according to its profile, which simplifies the development of the application.
- How it is managed: Rules can be defined (whose application will be conditioned based on the parameters of different users) in which the filters for the data to which you can access are defined. Finally, these rules will be assigned to the corresponding views/applets.
- From where it is configured: This can be done from Personalization Rules View.
- When the changes made are applied: Once the Customization Rules have been loaded again (option available in the rules list-applet menu).
- Value Lists: They are the best resource for handling collapsible list fields. However, it may happen that we do not want any user profile to be able to access all the active values of a specific list.
- How it is managed: It is possible to configure a LOV so that the values are filtered according to the Division to which the user belongs. The High field is used for this purpose. The filter will be applied to values in the list that have a ‘Y’ in that field.
- Where it is configured from: From Data Management/List of Values Relationship View.
- When the changes made are applied: It is only necessary to empty the cache.
- State model: Although it is designed to control the flow of states of the different entities, it can be applied to any other field that is based on a LOV to control that they cannot be modified ‘crazy’.
- How it is managed: It is applied on a BC, and therefore on any Applet based on it. We must specify the values of the LOV that we will consider valid, as well as the accepted transitions. On the latter, conditions can be established so that the change of value is allowed to be executed, and even filter these possible transitions so that they only appear available to users with certain Main Positions.
- Where it is configured from: From Application Management/State Model Detail View – States.
- When changes are applied: Requires that the Object Manager be restarted after configuration is complete.
- Custom ListApplets: Every time a user logs out and accesses the app again, they find the listings as they were left configured (order and width of columns, etc.). This information is collected in a file with SSF extension of the server. This gives us the possibility to copy the personal configuration of one user to another, or establish a default configuration in case we want to restore that of one. These files also include User Preferences.
- Where stored: In the “<siebel root>\bin\” directory
- Predefined queries: These queries allow us to facilitate users to filter data through queries without needing to enter their parameters.
- How it is managed: They can be generated directly from the corresponding view by writing the clause in SQL, or more easily if we execute the querie with any user, we save the query for that user, and from the configuration view we establish which users or Divisions can access.
- Where it’s configured from: From Predefined Query Administration View.
- When the changes made are applied: Immediately, it is only necessary to reload the view.
- Email templates: They are a good tool to define general email formats, use them for individual or mass campaigns, etc. (in the case of templates used in individual campaigns, I recommend the article published by Jorge Serrano about how to configure the communications profile of users so that they can use this functionality):
- How it is managed: A content is established, either text or HTML, and the subject of the mail is defined, as well as that Users or Divisions will have access to them. It is important that users who want to use them have their User Preferences correctly configured (where the Outgoing Communications tab establishes whether they have access to templates in Text or HTML format).
- Where it’s configured from: From Communication Management/All Templates (Comm Package Response Form Admin View).
- When the changes are applied: Once the template is saved, it is only necessary for the user to open a new session to view it.
