|   Release Notes   |   ScienceLogic Support   |   Tips for Using the Online Documentation   |   Contact Documentation


Overview of Concepts for Incident Management

Download this manual as a PDF file

This section introduces the concepts of Incident Management in SL1.

Navigation tips for the SL1 user interface:

This section covers the following topics:

Super Service Provider

In our examples, we will use the fictional company Super Service Provider.

The Network Operations Center (NOC) for Super Service Provider is responsible for monitoring service delivery, customer satisfaction, SLA compliance, and emergency management.

The NOC acts as the initial point of contact for all customer requests, incidents, and problems. NOC personnel either resolve the problem or escalate the ticket to the appropriate engineering teams.

Super Service Provider is governed by Service Level Agreements (SLAs) in place between Super Service Provider and its customers.


An organization is a group for managing elements and user accounts. All hardware, software, policies, events, tickets, and users in SL1 are associated with an organization.

The bare-bones characteristics of an organization are:

Organizations can be defined by geographic areas, departments, types of devices, or any structure that works best for your needs.

NOTE: For more details on organizations, see the section on Organizations and Users.

For our example, we will create two organizations:


A ticket is a request for work. This request can be in response to a problem that needs to be fixed, for routine maintenance, or for any type of work you require.

In this example, tickets can come from customers, an automated monitoring system, or an internal employee.

In this example, the request in each ticket can be classified into one of the following categories:

Ticket Source

Ticket source is a description of where the ticketed originated.

In this example, tickets originate from one of the following sources:

To comply with their Service Level Agreements and improve operational efficiency or workflow, Super Service Provider has policies in place to handles tickets from the various sources.

For example, NOC staff must review and triage tickets that are generated by customers through email or the portal. The NOC personnel will determine the appropriate severity and actions, and the correct engineering team to engage.

Tickets created by employees of Super Service Provider or from an automated management system can be placed directly into the queue that corresponds to the engineering team responsible for resolving the ticket.

Ticket Severity

Tickets are assigned a severity based on the severity of the issue that needs to be fixed or worked on. For example, a server going down might require a critical ticket, whereas a routine maintenance issue might require only a minor ticket. Ticket severities include healthy, notice, minor, major, and critical.

In our example, Super Service Provider uses severities to define the urgency of the problem, required response times, and SLAs. At Super Service Provider, work is classified using one of the following severities:

Ticket Status

Ticket status provides a quick way to monitor the stage or work for the ticket. The following are the possible ticket statuses:

In our example, Super Service Provider will examine ticket status to monitor compliance with Service Level Agreements. In addition, Super Service Provider will also examine the following information about each ticket to monitor compliance with Service Level Agreements:

Ticket Queues

Ticket queues allow you to organize and filter tickets. Organizing tickets by ticket queues and then assigning users to ticket queues allows each user to see only the tickets that are relevant to him/her.

You can also use ticket queues to move tickets through a pre-defined workflow. In our example, Super Service Provider will use the following ticket queues:

Service Level Agreements

A Service Level Agreement or SLA is a written contract between a service provider and its customers. An SLA describes the service that will be provided for each fee, the level of customer support, and the penalty when that service is not provided. For example, many Internet service providers use SLAs that specify percentage of uptime, guaranteed performance benchmarks, help-desk response time, and advance notification of changes that could affect the customer.

In our example, SLAs are based on ticket status (open, pending, working, resolved), the Assigned To value, and the severity (healthy, notice, minor, major, critical) of each ticket.

In our example, Super Service Provider is governed by several Service Level Agreements (SLAs) between Super Service Provider and its customers.

New Ticket SLAs

These SLAs determine the actions that Super Service Provider must perform on each new ticket and how quickly Super Service Provider must perform these actions.

Existing Ticket SLAs

These SLAs determine the actions that Super Service Provider must perform on each existing ticket after it has been assigned to an engineer and how quickly Super Service Provider must perform these actions.


Ticket escalation policies automatically perform actions on a ticket when specified conditions have been met.

For example, the escalation conditions could be "if a ticket has a severity of 'major,' is three days old, and has not yet been assigned to a user." When a ticket meets those conditions, the escalation policy could perform the actions "change ticket's severity to 'critical' and assign the ticket to the queue administrator."

In our example, we will create and use the following escalation policies: