Managing Users

Use the following general steps for establishing user accounts:

Determine the types of user accounts you need.
To better manage sets of users, log in to Application Administrator, and then create groups, such as "Release Engineers" and "Service Technicians."
Add accounts for each active user.
Assign users to the applicable groups you created. This will ease the process of assigning users to roles.
Assign groups to roles in each process app.

Types of Users

Before you add user accounts, consider the types of users you need. This helps you determine the product-access level you should assign to each user.

For example, Serena Request Center has two distinct types of users: requesters and fulfillers. Requesters are those who request IT services, such as logging a ticket to report a problem and asking for additional network access. Fulfillers are those who respond to requests by either directly working on them or by managing incoming requests to ensure that an organization's activities are streamlined.

Use the following information to determine which product-access type to assign to each set of users:

Occasional User
Assign to users who will use Serena Request Center to submit IT service requests. These users can also view and update the requests and proposals that they submitted.
Regular User
Assign to users who will fulfill requests.
Managed Administrator
Assign this product-access level to users who will configure Serena Request Center, administer your process apps in SBM Composer and Application Administrator, manage user accounts, and other administrative duties. By default, this product-access level is automatically granted to the user who establishes your on-demand account.

Adding User Accounts

Each active user in your system must have an account that includes:

Name and e-mail address
Product-access level
Group membership (optional, but recommended)

To add user accounts, log in to Application Administrator, and choose one of the following methods:

Select the Users icon and manually add individual user accounts.
Select the Import Users icon to import users from a spreadsheet or from an LDAP store.

For details steps on adding or importing users, creating groups, and assigning users to groups, click Help in Application Administrator.

Assigning Users to Roles

After you establish accounts for each user in your system, assign these users to applicable roles in Application Administrator using the following guidelines.

Product-access Level	General Guidance	Example
Occasional User	Assign these users to roles intended for IT customers and planners who submit requests and who need to view and update their requests later.	Incident Users (SSM - Incident Management) Service Request Users (SRC - Service Request)
Regular User	Assign these users to roles intended for IT staff who will fulfill requests submitted by IT customers.	Level 2 Techs (SSM - Incident Management) Editor/Publisher (SRC - Knowledge Management)
Managed Administrator	Assign these users to roles intended for users who will administer the process app in Application Administrator, SBM Composer, and Application Repository.	CMS Administrator (SSM - Configuration Management System) PM Administrator (SSM - Problem Management)

Product-access Level

General Guidance

Example

Occasional User

Assign these users to roles intended for IT customers and planners who submit requests and who need to view and update their requests later.

Incident Users (SSM - Incident Management)

Service Request Users (SRC - Service Request)

Regular User

Assign these users to roles intended for IT staff who will fulfill requests submitted by IT customers.

Level 2 Techs (SSM - Incident Management)

Editor/Publisher (SRC - Knowledge Management)

Managed Administrator

Assign these users to roles intended for users who will administer the process app in Application Administrator, SBM Composer, and Application Repository.

CMS Administrator (SSM - Configuration Management System)

PM Administrator (SSM - Problem Management)

Group Queues

Group queues keep items from being missed or delayed if individuals are absent when items are submitted or move into an investigation state because the entire group has visibility and ownership of items. In addition, items with a primary owner can be reassigned to the group queue.

The following applications allow items to move into a group queue, where team members are secondary owners and can assign items to themselves or to someone else on the team:

Service Request
Incident Management
Change Management
Problem Management

An item can be assigned to both a group and an individual, or to one or the other. This allows users to assign an item directly to the appropriate individual without having to move it into a queue state.

If an individual is selected, he or she becomes the Owner of the item, and if a group is also selected, it becomes the Secondary Owner.
If a group (or individuals in a Multi-Group field) are selected, the group or individuals become the Secondary Owner; there is no Owner.

For example:

An incident is assigned directly to Jim, a Level 1 Technician. Level 1 Group is selected in the group field, which is optional. The item moves to the Investigation & Diagnosis state, where Jim is the owner, and Level 1 Group is the secondary owner. Jim starts working on the item, but is called to a customer site to handle an emergency. Sally is also a member of the Level 1 Group. She reassigns the item back to the group queue and then assigns it to herself to complete.
Note: If no group is selected in the group field, only Jim has direct knowledge of the item while he is the owner, so the benefits of group queues will not be realized.
An incident is assigned directly to the Level 1 Group and moves to the Investigation Queue state. Level 1 Group is the secondary owner; there is no owner. Carlos opens his Worklist Dashboard report, sees the item in the group queue, assigns it to himself, and resolves the incident. As in the first example, if he were unable to start or complete his work, another member of the group could reassign the issue back to the group queue for someone else to work on.

The provided applications listed at the beginning of this topic include special dashboard reports that show the number of items in queue states and the items for which the current user is a primary or secondary owner. The queue states in these applications have Operational Level Agreements (OLAs) that stipulate how long items can remain in queue. E-mail notifications defined for the OLAs warn users when items are at risk or in violation of the agreements.

The following steps should be followed if you want to customize the implementation of group queues.

In SBM Application Administrator:

Assign users to groups.
Assign these groups to the roles that were associated with Multi-User and Multi-Group fields in SBM Composer. For example, Carlos is in the IM Technician group, which is assigned to the Level 1 Techs role. This role is associated with the Level 1 Group Multi-User field, so Carlos can be selected when an item is assigned to a technician and is a secondary owner when the item is in a queue state.
Define Operational Level Agreements (OLAs) or Service Level Agreements (SLAs) for the queue states.
Subscribe the groups to notifications. For example, if the group is subscribed to the "I become the owner of any Incident" notification, all group members will be notified when an item moves into a state in which the group is the secondary owner.

Note: For details, see the SBM Application Administrator Guide.

In SBM Composer:

Associate roles with Multi-User and Multi-Group fields in primary tables. For example, you could associate the Level 1 Techs, Level 2 Techs, and Level 3 Techs roles with the Incident Operators field.
Set the selection mode for the Multi-User fields to Groups & users.
Use decisions in application workflows to route items to "work" states when an individual owner is specified or to "queue" states when a group is specified.
Assign the group fields as secondary owners of the "work" and "queue" states in application workflows. (The Secondary Owner system field must be added to the primary table before you can do this.)

Note: For details, see the SBM Composer Guide.