Custom Ticket States

A custom ticket state is an additional ticket parameter. The definition of a ticket state includes logic that you can use to control workflow. Using a custom ticket state, you can specify that tickets with the custom state will always have a specified status and ticket queue. You can also specify that tickets with a custom state can be moved only to the specified ticket queue(s) and can be changed only to specified custom states.

You can create, edit, or delete custom ticket states from the Ticket States page (Registry > Ticketing > Custom States).

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

Viewing a List of Existing Ticket States

You can view existing custom ticket states from the Ticket States page (Registry > Ticketing > Custom States). The Ticket States page displays a list of existing ticket states.

To view a list of exiting custom ticket states:

Go to the Ticket States page (Registry > Ticketing > Custom States).
For each custom ticket state, the Ticket States page displays the following information:

To sort the list of ticket states, click on a column heading. The list will be sorted by the column value, in ascending order. To sort by descending order, click the column heading again. The Edit Date column sorts by descending order on the first click; to sort by ascending order, click the column-heading again.

State Name. Name of the custom ticket state.
Tickets. Number of tickets aligned with the ticket state.
Default. Specifies if this is the default ticket state. SL1 automatically assigns the default ticket state to new tickets.
ID. A numeric ID, generated by SL1, that uniquely identifies this ticket state.
Edited By. The user who created or last edited the ticket state.
Edited On. The date and time the ticket state was created or last edited.

Creating a Custom Ticket State

You can create a custom ticket state from the Ticket States page. After you create a custom ticket state, it will appear in the Ticket State field when defining or editing a ticket in the Ticket Editor page.

To create a custom ticket state:

Go to the Ticket States page (Registry > Ticketing > Custom States).
In the Ticket States page, click the Create button. The Ticket State Definition modal page appears.
In the Ticket State Definition modal page, supply a value in each of the following fields:

State Name. Name of the ticket state. Can be any combination of alphanumeric characters.
Aligned Ticket Status. When tickets are assigned the ticket state, SL1 will automatically assign this status to the ticket. Choices are:

None
Open
Working
Pending
Resolved

Force Aligned Status. Specifies whether users can change the original ticket status for tickets that are assigned the ticket state. Choice are:

No. Within the Ticket Editor page, users can edit the ticket status (specified in the Align Ticket Status field) assigned to tickets that use this ticket state.
Yes. Users cannot change the ticket status (specified in the Align Ticket Status field) assigned to tickets that use this ticket state.

Change Status. For all selected tickets, changes the value in the "Status" field. In the drop-down list to the right, you can select from a list of the following statuses:

Open. Ticket has been created.
Pending. Ticket has been acknowledged.

Working. Someone is working on the ticket.
Resolved. Issue has been resolved. When a parent ticket is resolved, its children tickets are automatically resolved. When you select this option, SL1 displays the Ticket Resolution modal page.

NOTE: If all Ticket States have the Force Aligned Status field set to Yes, the Ticket Console page will not display the Change Status option in the Select Actions menu.

Default Ticket Queue. When tickets are assigned the ticket state, SL1 will automatically assign the tickets to the selected Ticket Queue. Select from the list of all available ticket queues.
Force Queue on State Change. Specifies whether users can change the original ticket queue for tickets that are assigned the ticket state. Choices are:

No. Within the Ticket Editor page, users can edit the ticket queue (specified in the Default Ticket Queue field) assigned to tickets that use this ticket state.
Yes. Users cannot change the ticket queue (specified in the Default Ticket Queue field) assigned to tickets that use this ticket state.

Allowable Ticket Queues. If you select one or more ticket queues from this list, in the Ticket Editor page, users can change the ticket queue (specified in the Default Ticket Queue field) assigned to tickets that use this ticket state. Users can move tickets only to the queues selected in the Allowable Ticket Queues field. If you don't want to allow users to change a ticket's queue, do not select any ticket queues in this field.
Allowable new states. If you select one or more ticket states from this list, in the Ticket Editor page, users can change the ticket state assigned to tickets that use the current ticket state. Users can move tickets only to the ticket states selected in the Allowable new states field. If you don't want to allow users to change a ticket's ticket state, do not select any ticket states in this field.
Key(s) to set this State. Specifies the access keys required to assign this ticket state to a ticket. Displays a list of all existing access keys. You can select one or more access keys.

If you do not specify an access key, no specific access keys are required to assign this ticket state to a ticket.

None of the existing access hooks directly correspond to assigning a custom ticket state. Therefore, you might want to create an empty access key to correspond to a ticket state. For example, suppose you created a ticket state called "confirmed_defect". You could create an access key called "confirmed_defect" but not assign any access hooks to the access key. You could then require that users be assigned the access key called "confirmed_defect" to use the ticket state called "confirmed_defect". To read more about access hooks and access keys, see Ticket Settings and Customization.

Make this the default state. Select this checkbox if you would like this custom state to become the default custom ticket state.

To clear the values you have inserted, click the Reset button. To save the new ticket state, click the Save button.

Editing and Deleting Custom Ticket States

You can edit and delete existing custom ticket states from the Ticket States page. You can edit individual custom ticket states, and delete multiple or all ticket states.

To edit a custom ticket state:

Go to the Ticket States page (Registry > Ticketing > Custom States).
In the Ticket States page, find the ticket state you want to edit. Click its wrench icon (). The Ticket States Definition Editor modal page appears.
You can edit the values in one or more fields described above in the section Creating a Custom Ticket State.
Click the Save button to save your changes to the ticket state. Click the Save As button to save your changes as a new ticket state.

You can also delete individual, multiple, or all custom ticket states from the Ticket States page.

To delete one or more custom ticket states:

Go to the Ticket States page (Registry > Ticketing > Custom States).

In the Ticket States page, find the ticket state(s) you want to delete. Select its checkbox ().
Select the checkbox for each ticket state you want to delete.
In the Select Action drop-down list at the bottom of the page, select Delete State(s). Click the Go button.
If no tickets are currently using the ticket state, each ticket state is deleted.
If one or more tickets are currently using one or more of the ticket state(s) selected for deletion, the State Removal modal page appears. In this page, you are asked to perform an action before the ticket state can be removed. Your choices are:

Clear state for tickets in this state. Each ticket that was using the deleted ticket state will be assigned the default ticket state (if one exists) or will not have a ticket state.
Set tickets in this state to a different state. If you select this option, you can select a New State to assign to the tickets that are currently using the deleted state.
New State. Displays a list of ticket states. The selected ticket state will be assigned to affected tickets as a replacement for the deleted ticket state.

After selecting an option, click the Delete button to apply the option and delete the selected ticket states.

Example: Creating Custom Ticket States

In this example we will create different ticket states for a ticket going through a quality assurance workflow. We will create four different ticket states and pass a ticket through the workflow stages—from ticket creation to resolution—using these custom states.

In this example we will assume we are a company providing Internet service to customers. Our company has a designated workflow for tickets and already has two defined ticket queues: Quality Assurance and Workflow Manager. To read more about creating a ticket queue, see Ticket Queues.

After a ticket for a problem is created, the ticket will go to the Quality Assurance queue, where a member of the team will work on the ticket. After work has been completed on the ticket, it must be passed to the Workflow Manager before the ticket can be resolved. In this example we will create custom ticket states to make passing a ticket through the stages of workflow as efficient as possible.

Our first ticket step is to create a custom ticket state for tickets that have been created and assigned to a user in our Quality Assurance team. To create this custom ticket state:

Go to the Ticket States page (Registry > Ticketing > Custom States).

In the Ticket States page, click the Create button. The Ticket States Definition Editor page appears, where we defined the following values:

State Name. We named our custom state "Ticket Assigned".

Aligned Ticket Status. Because this is custom state for a ticket that has just been created, we set this field to "Open".
Force Aligned Status. Because we want the user assigned this ticket to have the ability to change the ticket's status, we selected "No."
Default Ticket Queue. This is the queue the ticket will be sent to after it has been assigned a custom state. We selected "Quality Assurance."
Allowable Ticket Queues. After work has been completed on a ticket, we want the user to be able to send the ticket to the manager of workflow. We selected "Workflow Manager" so the user can pass the ticket to this queue. We also selected "Quality Assurance," because we want the ticket to initially be assigned to this ticket queue.
Allowable new states. Because we haven't created all of our ticket states yet, we left this field blank. After we have created all of our custom states, we can edit the "Ticket Assigned" state to add custom states.

Key(s) to set this State. Because we do not want users to pass a ticket without manager approval, we selected a custom Access Key, "Ticket: Resolve." In this example we can assume this key will allow a user to work on a ticket, but will not allow them to resolve the ticket. To learn more about creating Access Hooks and Access Keys, see the section on Access Permissions.
Make this the default state. We selected this checkbox to make all created tickets use this custom state.

Click the Save button to save the "Ticket Assigned" custom ticket state.
We must now create three more custom ticket states: "Ticket - Work Complete", "Ticket - Failed", and "Ticket - Passed".

To create the "Ticket - Work Complete" custom state, repeat steps 1-2 with the following changes in the Ticket State Definition page:

State Name. Name the custom state "Ticket - Work Complete."

Aligned Ticket Status. Align to ticket status "Pending", because the work has been finished on the ticket but needs to be passed to the workflow manager before the ticket can be resolved.
Allowable Ticket Queue. Select "Workflow Manager".
Key(s) to set this State. Because the manager of workflow will be working on this ticket at this custom state, we granted them all access permissions.

To create the "Ticket - Failed" custom state, repeat steps 1-2 with the following changes in the Ticket State Definition page:

State Name. Name the custom state "Ticket - Failed".
Allowable Ticket Queue. Select "Workflow Manager" and "Quality Assurance."

To create the "Ticket - Passed" custom state, repeat steps 1-2 with the following changes in the Ticket State Definition page:

State Name. Name the custom state "Ticket - Passed".
Aligned Ticket Status. Align to ticket status "Resolved".
Allowable Ticket Queues. Leave this field blank. Because the ticket has passed and can be resolved, it does not need to be assigned to another ticket queue.

We now have our four custom ticket states created and can add Allowable new states to each created state. An allowable state lets you define the additional custom ticket state(s) a ticket can be assigned based on its current ticket state.
To edit a ticket state, click its wrench icon () to bring up the Ticket State Definition page. For the custom ticket states we created, we added the following Allowable new states:

Ticket - Assigned. After a ticket has been created it will be assigned to a member of the Quality Assurance team. That team member will work on the ticket until complete. We added the "Ticket - Work Complete" state to this custom state. A ticket with a state of "Ticket - Assigned" can be moved to the state "Ticket - Work Complete".
Ticket - Work Complete. After work has been completed on a ticket, it needs to be sent to the workflow manager to review (pass or fail) the ticket. We added "Ticket-Failed" and "Ticket-Passed" to this custom state. A ticket with a state of "Ticket - Work Compete" can be moved to either the state "Ticket - Failed" or the state "Ticket - Passed"
Ticket - Failed. If a ticket is failed it will need to be sent back to the Quality Assurance team for more work. We added "Ticket - Assigned" to this custom state. A ticket with a state of "Ticket - Failed" can be moved to the state "Ticket - Assigned".
Ticket - Passed. Because the ticket has been passed and can be resolved, we did not add any more allowable custom states.

We have now created our four custom ticket states and can pass a ticket through them. In this example we will assume a ticket has been created due to a spelling error in our the ScienceLogic Support Site.

After the ticket has been created:

It will use the "Ticket Assigned" custom state
It will be assigned to a user we specify in the Quality Assurance queue:

In this example we will assume that the user completed this work on the ticket.

The user changes the status of the ticket to "Pending".
The user will now need to send the ticket to the workflow manager for approval.

In the Ticket State drop-down list, the only custom state available is "Ticket-Work Complete". The user selects this option, and SL1 will automatically assign the ticket to the "Workflow Manager" queue:

After the ticket has been changed to the "Ticket-Work Complete" state, the workflow manager can review the ticket and determine if it will pass or fail.

In this example the workflow manager has found the spelling error still exists on the portal, and the ticket will need to be failed. In the Ticket State field, the manager can select the state "Ticket-Failed."
After the ticket is moved to the state "Ticket - Failed". the ticket will automatically be reassigned to the Quality Assurance queue.

Now that the ticket is failed back to the Quality Assurance queue, it will need to be set back to its original state of "Ticket Assigned" so a member of the Quality Assurance team can begin working on it again. The "Ticket Assigned" state is the only other state available in the Ticket State drop-down list. Because the ticket is currently already in the Quality Assurance queue, selecting the "Ticket Assigned" custom state will not change the queue.

The ticket is now back in its original custom state. We can assume that the user has worked on the ticket again and has changed the state to "Ticket-Work Complete" to send to the portal manager.

After reviewing the ticket and seeing the work has been completed, the portal manager can now pass the ticket. When the manager changes the ticket state to "Ticket - Passed", the manager can change the ticket's status to Resolved (the Aligned Ticket Status for "Ticket - Passed" is set to Resolved). To learn more about resolving tickets, see Resolving Tickets.