By @lex on Oct 02, 2008
The ability to respond: Responsibility
It seems futile to write a blog post about responsibilities in Siebel CRM. Everyone knows that they are used to grant access to views. But if you look closer, there is more than that, especially in newer versions of Siebel.
But let me begin with a different perspective. Let’s consider an ideal project, where business analysts follow the golden rule to document the existing processes and start on a high level with mapping the process steps to Siebel views. They would put that information down in a spreadsheet. Then they would extend the spreadsheet with information about the details for every step such as which fields should be filled with what values.
The analysts would also analyze the end user community and identify groups of users who have to execute similar processes.
Finally they would identify gaps in the standard application and design solutions for these gaps. For example a missing field would have to be created by the developer.
Besides the fact that this ideal analyst behavior is rarely found, what does business process analysis or business processes in general have to do with responsibilities?
Consider the graphic below as an attempt to depict the facts stated above. When you start viewing a business process as a set of steps which are carried out in a Siebel view then you need to give all users who have to execute the business process access to these views. So the group maps to the Siebel entity we know as responsibility.
A Siebel Responsibility allows an employee to execute one or more business processes in the Siebel application by granting access to the necessary views. If you conduct a decent business process analysis and documentation, you end up with all the information you need to create both the administrative data (i.e. responsibility and their associations with views and users) and the end user guidance either with iHelp or Task UI.
But there is more to business processes than just navigating from one view to the other and manipulating data. As we discussed in “Close to the Standard”, much of the functionality and automation behind the UI is implemented using business services and workflows, so they are a part of the business process.
And indeed, responsibilities also allow an administrator to grant access to business services and workflows (since version 8.0). The detail views in the Administration – Application > Responsibilities view clearly indicate this (Note that Business Process is used synonymously for Workflow Process).
Responsibilities also allow an administrator to override the sequence of screen and view tabs by creating individual tab layouts for each combination of responsibility and application. The primary responsibility of an end user will be the driver for the sequence of screen and view tabs that an end user sees after logging in. Tab layout can also be overriden by the end user in the User Preferences > Tab Layout view.
In Siebel 7.5 a simple list applet appeared on the home page view which was labeled "Tasks" offering links to views (as the starting point of a business process such as "Create a service request"). The content of this applet is also driven by the primary responsibility of an end user. Because of the naming conflict with the UI Tasks in Siebel 8.0 the applet and view tab were renamed to "Links".
Responsibilities also provide access to UI Tasks and iHelp items which are the two main tools to guide end users through a business process. So we are back where we started our journey: Responsibilities have a direct relationship to business processes and the application functionality that lies within them.
Let’s summarize the objects which responsibilities can provide access to:
- Views, of course
- Tab Layout
- Links (to views)
- Business Services and Methods
- iHelp Items
- Tasks (Siebel 8.0 Task UI)