Applications → Creating Roles → About Roles → Use Cases for Roles
In SBM, the process design environment (SBM Composer) is independent of the administration environment where you are concerned with specific projects, users, and groups. At design time, you might not know which specific users or groups will interact with the application that you are creating or modifying; however, you still need to be concerned with privileges from a design standpoint. Roles are the solution to this problem, because in the design environment, a role is associated with privileges but not with specific users or groups.
If you are administering an application in the runtime environment, you must assign actual users (individually or as members of groups) to roles for each project. A given user or group could have different roles in different projects. For example, two projects could have two different people assigned to the Build Manager role. The role is the same, but the person filling the role for a specific project (or for a specific deployment of the process app) is different.
A good place to start when deciding what roles to create is to look at the user-type fields in your primary items—particularly fields that determine ownership for items. For example, if you have an Engineer field that determines ownership of an item in a particular state, Engineer might be an appropriate role to create.
The following sections describe various ways you can use roles.
Every application has two default roles: Administrator and User. These broad roles could be adequate in simple applications. However, most applications require more specialized roles.
In an employee time-off application, there could be Employee, Manager, and Payroll roles. The Manager and Payroll roles have privileges that are not part of the Employee role. For example, the Manager role could have the Delete Items privilege. The Advanced Fields section might be for payroll purposes only, so the Payroll role would have the Advanced Fields privileges.
Employees requesting vacation time have the Employee role, the employee's manager who approves or rejects the request has the Employee and Manager roles, and the payroll clerk has the Employee and Payroll roles. Because privileges are cumulative, the manager has all of the privileges granted by the Employee role, as well as any additional privileges granted by the Manager role. Similarly, the payroll clerk has all of the privileges granted by the Employee role, as well as any additional privileges granted by the Payroll role.
Administrators create groups to limit the number of privilege sets that they need to maintain. For example, there could be a group called Development Team. The members of the group include individual users associated with the Engineering, Quality Assurance, and Documentation roles. Suppose a system privilege needs to be added for these users. An administrator can use SBM Application Administrator to quickly add the system privilege to the group, and the privilege set for all of the individual users would be updated.
In an issue management application, after engineers finish fixing an issue, they transition the issue from the Fixing Issue state to the Peer Review state. In this state, another engineer reviews the code that the first engineer changed to fix the issue. The owner of the Peer Review state is Peer Reviewer, which is a User field associated with the Engineer role.
The engineer selects the peer reviewer from a list box that is populated with users with the Engineer role.
In a change request application, after a technical analyst determines that a change request should be considered by the Change Approval Board (CAB), he or she transitions the change request to the In Review state. The owner of this state is Reviewers, which is a Multi-User field associated with the CAB Members role. This role has privileges to own and view change requests, but not submit or delete them.
The technical analyst selects the appropriate board members from a list box that is populated with all users with the CAB Members role.
Multi-Group fields are useful when you want to take advantage of queueing. Queueing takes place when users evaluate issues in a backlog and assign certain issues to themselves.
For example, in a help desk application for a company, employees submit issues for technical problems they are experiencing. The issues move into a Backlog state. The secondary owner for this state is a Multi-Group field called Employee Location. This field is associated with two roles: Technician and Manager. The Manager role is associated with the field because managers often work part-time as managers and part-time as technicians.
The Employee Location field is populated by groups that represent the various company sites. Each group is comprised of technicians and managers who are located at the site. All of the technicians and managers at the selected site own the issues in the Backlog state, and can assign the issues to themselves.
Privileges are additive and can be indifferent to the role-based transition restrictions specified on the Restrict By Role Tab of the Transition Property Editor. This means that all privileges granted to all roles are initially put into a pool, and after that, role-based transition restrictions are considered. For example, suppose the Manager role is not restricted from the Escalate transition, and has the "Transition Item if Owner" privilege. Laura is associated with the Manager role, but she is not the owner of the source state. Therefore, she should not be able to access the Escalate transition.
However, Laura is associated with another role, the Engineer role. The Engineer role is restricted from the Escalate transition, but has the "Transition All Items" privilege. The Engineer role privileges are added to the pool of privileges granted to Laura. Therefore, Laura can access this transition, even though she is not the owner of the source state.
Copyright © 2007–2015 Serena Software, Inc. All rights reserved.