General Features

Role-based Access

For each process, administrators can map functional and access privileges to users by assigning the appropriate roles.

Access to items and data are controlled by roles. Roles can grant read-only access to one group and update privileges to another. Data attributes can also be classified, and access to each data classification can be granted by role.

Functional privileges include access to and ownership of items in a workflow. The ability to transition items from one state to another is also controlled by role privileges. Furthermore, owners are assigned to each active state in a workflow.

Roles are customizable, allowing you to tailor the roles to your installation.

Group Queues

Note: 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

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 back to the group queue.

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.

Workflow Rules

Workflow rules determine how an item should progress through the workflow, and whether certain criteria must be met before an action can be performed. These actions can be performed automatically.

For example, workflow rules can be established to ensure that a CI has valid data. If these conditions are not met, an automated action can be launched on the item, such as preventing the item from being transitioned to the next state.

Service Level Agreement Compliance

A Service Level Agreement (SLA) defines the level of service that an organization commits to its customers. Projects can be associated with a specific SLA, allowing you to track SLA compliance for items submitted in that project.

The SLA widget displays the status of the current SLAs that pertain to an item. This widget is included on state forms for both Incident Management and Service Requests.

Tip: You can add the SLA widget to your custom state forms using SBM Composer.

SLA reports are available to managers who can access historical information to measure how well their organization conformed to SLAs and forecast information to ensure that active items are not in danger of violating them.

Audit Trails

Service Manager includes the complete tracking functionality of SBM, which enables you to track changes to every item. Each item is assigned a unique identifier after it is created in SBM. Every activity is recorded, including field updates, transitions, and relationships, as the item moves through the workflow.

You can access this data by viewing the Change History of the item or by running reports. This data provides an audit trail for the item throughout its life cycle; you can use this data to improve your processes.

Auxiliary Tables

Multiple auxiliary tables are included that contain values that are used by selection fields. The values for these fields can be easily changed by modifying the auxiliary tables.

Custom Form Actions

Serena Service Manager process apps include special custom form actions. They appear in the Actions tab of the form Property Editor in SBM Composer when you create statements for events, conditions, and actions. The custom form actions include:

Events
- execute immediately: Executes the action immediately when the form begins to load, instead of waiting for it to load completely.

Conditions
- an SOO process application is deployed: Checks whether the selected process app has been deployed.
- this form is zoomed/not zoomed: Checks whether the form is in a zoomed view, such as when it is viewed from a multi-view report.
- this form is in a shell: Checks whether the form loaded from a shell, such as Request Center.
- current user is in a Multi-User field: Checks whether the current user is included in the selected Multi-User field.
- format and compare two date fields: Formats two "Date only" Date/Time fields and then compares their values. You can check whether one is later than the other, or whether one is the same as or later than the other. If one of the fields is empty, the condition will evaluate to true.

Actions
- do SOO form formatting: Detects the type of form that is displayed (state or transition) and applies the standard formatting for that type of form.
- initialize SOO utils: Pre-loads the SOO utility JavaScript and CSS files. By default, they are loaded on first use.
- add more actions widget to an action control: Links the More Actions menu to the selected action control.
- format a tab with new tab style: Applies either the grey bar or the wizard tab style to the selected tab control.
- toggle sidebar control: Displays a control that the user can use to toggle whether the sidebar is shown or hidden.
- collapse sidebar control: Collapses the sidebar so it is hidden, with no control for the user to show it.
- expand sidebar control: Expands the sidebar so it is shown, with no control for the user to hide it.
- add/remove current user to/from a Multi-User field: Adds the current user to or removes the current user from the selected Multi-User field.