Home > Supervisor Guide > Service > Service > Workflows > Incident & Problem Workflows

Incident & Problem Workflows

Workflows define the sequence of States to be followed by requests logged with the application. Within the system an unlimited number of Workflows can be configured for Incident and Problem Management.

When deployed, the system includes one fully customizable Workflow for each of the Incident and Problem Management Processes. These can be used immediately, or can be edited to reflect more comprehensively your support service requirements.

SLAs and Workflows

Each Workflow can be associated with one or more SLAs. The SLA provides the contract time that must be met by requests using the Workflow.

For example, if the Service Desk uses one Incident Workflow, which has multiple SLAs assigned to it, logged Incidents follow the same Lifecycle but the time allowed within each stage is based on the SLA contract requirements. The SLA assigned to either the Item, Customer, Organizational Unit or Incident determines which Workflow is selected for the Incident.

Editing default Incident and Problem Workflows

Incident and Problem Workflows can be configured to reflect the organizational Service Desk requirements for these processes. The default Workflows include States that are used by the business logic of the application to maintain control of the request Lifecycle.

It is recommended that the Selected States used by the application, as indicated by an asterisk, not be removed from the Workflow Lifecycle. However, other Available States can be added to the Selected States list.

The following table contains the default Incident and Problem Workflow States.
The * denotes the system-used States.

Default State	Description
Cancelled	Used to cancel a request when it is no longer to be worked on.
Cancelled Unpaid*	Used by the system from the Pending - No Contract State when Contracts and Invoices are enabled. See Billing.
Closed Resolved	Used when the request has been resolved. This is the Default Closed State for the Incident and Problem Workflows. This start marks the end of SLA timing and is used when measuring SLA times for Reports.
Closed Restored	Used when the request has been closed and the service restored for the Customer. This start marks the end of SLA timing and is used when measuring SLA times for Reports.
On Hold	Used when the request is on hold. By default this State stops SLA timing.
On Hold - Client Action	Awaiting a response from the Customer. When a Note is added to the request by the Customer, the system will change the status to Open.
On Hold - Pending Approval*	An Incident automatically moves to this State when the "Propose" button is used for sending an Incident Note. This means the CloseRequest email is sent to the Customer asking them to verify the proposed Solution. If the Customer does not respond to the email, the request is automatically closed by the number of days set within the Handshaking Privilege. (The email handshaking option is set by the Administrator in Setup>Privileges> Requests.) By clicking on the URL provided in the email, the Customer ensures the request retains an open and active state.
On Hold - Process Escalated*	A request moves into this state when a Problem or Change has been created within the Analysis tab of the request. The timer stops and there are no future States as the request will be closed when the related Problem or Change is closed.
Open	Used to indicate that the request is currently open.
Open Restored	Used to identify that initial service to the Customer has been restored, or a Workaround is in place but the request is not resolved. This State stops the initial Response Timer if a Note has not been added to the request by a Technician.
Pending	The default first State for new requests.
Pending - No Contract*	Used when a request is created but there is no active Contract. A Contract needs to be created for either the Customer, Incident/Problem, Item or Organizational Unit. Do not use this State as the Default Open State for a Workflow.

Editing Template Workflows

Prior to creating or editing existing Workflows, it is suggested that the preferred Workflow Lifecycle be mapped externally to the application.

If States are to be added or removed from the Workflow, it is recommended that all changes be made to the Current States list within a Workflow's Lifecycle tab, prior to mapping the Lifecycle. This ensures that all relevant status options exist in the Available States field, for allocation to the Previous and Next Workflow States.

Once the Workflow Lifecycle has been defined, edit an existing Workflow by:

Select Service>Workflows
The Workflows screen appears.

Click the Workflow name hyperlink to modify or duplicate an existing template
Or, select New to create an entirely new Workflow. The Workflow tab appears and is used to define the Name, select the Process, set the default Open and Closed States for the Workflow. The States available within these lists are all those marked as an Entry or Exit point in the Lifecycle tab
Click Edit
The Duplicate button is displayed, select if relevant.
Complete the details of a new Workflow
Enter the Name, select the Process and enter a Description and click Next.

In Edit mode amend relevant details within the Workflows tab:

Field Name	Description
Workflow Name	Enter a relevant name for the Workflow.
Process	Select from the drop-down options the process type of Incident or Problem Workflow.
Default Open Status	The open State that a request adopts when it is assigned the Workflow.
Default Closed Status	The closed State that indicates the request has reached the end of the Workflow Lifecycle.
Email Note Action	This applies to requests that are in an non-active SLA State (i.e., where the SLA Active option is set to No). The option selected here determines the system behavior, regarding an SLA inactive request, when an email is received from a Customer. Do Nothing: Means the status of the request remains the same and the SLA timers are not re-activated. The email is added as a Note and also sent to the Technician. Update Status: Means the status of the request is changed to an SLA Timer Active state, the email is added as a Note and it also sent to the Technician.
Update Status to	This field is displayed when the Update Status option is selected for the Email Note Action field. It allows the User to set a Next State, which is defined as an SLA Timer Active State, where a request will move to after an email has been received from a Customer regarding a request in an inactive SLA State.
SLA	Allows the User to assign an SLA to govern the lifecycle period of the Workflow.(See SLAs & Workflows above, for more information.) One or more SLAs can be associated with the Workflow.
Description	Defines the purpose of the Workflow

Use the Find SLA option to change or add SLAs assigned to the Workflow.
Click to access the complete list of SLAs in the system. Refer to the above section for more information regarding SLAs and Workflows.
Note: Ensure you assign an SLA to Workflow before using the Workflow.

Edit the brief description that explains the purpose of the Workflow, if required

The Contract Time field is visible when OLAs and/or Underpinning Contracts are associated with the Workflow States
It displays the accumulated amount of time of the OLAs and/or Underpinning Contract associated with the stages of the Workflow. This contract time cannot exceed the resolution time of the SLA assigned to the Workflow.

Click Save
Select the Lifecycle tab to define Workflow States

Adding or editing Workflow States:

Edit the State details
Click the State name hyperlink in the Workflow map or in the table of States, to display the Status information screen. Or, click New to create a new Workflow State.

Status
Name	System Required States, the States marked with an asterisk in the States Table, can be re-named if desired. For newly created States, enter a name.
Active State	Assign Yes for requests to be available in the Home tab by default, when assigned to this stage of the Workflow. Yes should be used for States where the User is actively working on the request or waiting for updates."No" generally applies to Workflow exit points and will only be available by default within the relevant Process tab list view.
Entry Point	An Entry Point is used to indicate the start of a Lifecycle. To make the state a Workflow Entry Point, select the Entry Point checkbox. As the Entry Point is the first state, the Previous States field will be removed.
Exit Point	Select whether the State will be an Exit Point. An Exit Point is used to indicate the end of a Lifecycle. A Workflow can have only one Entry Point but multiple Exit Points.
Has Notes	Allows the Supervisor to include instructions or add relevant details for requests that move into this State. The information is configured within the Articles tab that is displayed when this option is enabled.
Listener Class	This field is visible if the Outbound Web Services option is enabled in the Admin>Setup>Privileges>System tab. Complete this field, if assigning this State to a request is to trigger an event in an external system. This field should contain the name of a Java class that implements the interface com.livetime.ws.listenWorkflowListener that has been compiled into a jar file and added to the LiveTime classpath. Please contact support for further details.
SLA Active	Links the status with timing set within SLAs and OLAs. When the option is set to No, the SLA/OLA timers stop and the triggers for escalations and warnings do not fire.
SLA Restoration	When timing is set using SLAs and OLAs, the SLA Restoration Time trigger is disabled when the request is moved to this state. Restoration Time indicates a Customer has access restored or a temporary workaround. Reports on Restoration Time are measured from when the Restoration Time trigger is disabled.
SLA Resolution	Allows the State selected to be used to mark the SLA Resolution Time. This will be used in SLA reporting.
Contract Type	Defines if the Workflow State will be managed by an internal (OLA) or external (Underpinning Contract) support agreement. If OLAs or Underpinning Contracts are assigned to a Workflow Lifecycle, the Workflow SLA Resolution Time cannot be exceeded by the sum of Resolution Times for all Contract Types assigned to the Workflow Lifecycle.
Assign SLM	This field is displayed when an UC is associated with the Workflow State. Use this field to define if the request ownership is to be maintained by the Assigned Technician or moved to the Manager of the SLA associated with the request.
Previous States	If the State is not an Entry Point, use the arrow button to select Previous States from the Available States and choose when this State will appear as a drop-down menu option in the Next Action field.
Next States	If the State is not an Exit Point, use the arrow button to select the Next States. A request can move to, in the Next Action field of a request Information Summary tab.

Delete the State if required, or Name/Rename the State
Enter all State information up to the SLA Resolution field
Save the updated State details

It is recommended all States that are to be included in the Workflow be added or re-named now
After all States have been entered in the system, the mapping of the Workflow can be more easily achieved.

Continue to edit, add or delete States until all relevant States exist for the Workflow
To create the Workflow Lifecycle, States need to be assigned to the transitional states of Previous and/or Next
To move Available States to the Previous State or Next State field, open the Status Details screen by clicking the State object in the Workflow map or select the State hyperlink in the table beneath the Workflow map.
Assign States to be Next and/or Previous States
For the Current Status highlight an option in the Available State list and click the right-pointing arrow to move it to the Selected States field.
When a State is used as a Previous and a Next State, it allows a request to move forward and backward in a Lifecycle
An Open State cannot have any previous States and a Closed State cannot have any Next States.

Click Save to return to the Workflow map and to access other States to build on the Workflow Lifecycle
Repeat Steps 14 to 16 until all transitional stages of the Workflow have been mapped

To successfully save a Workflow, the sum Resolution Time of the individual Contract Types assigned to each transitional state of the Workflow Lifecycle, must be less than or equal to the Workflow's SLA Resolution Time

Click Save.
The visual representation of the Workflow is displayed.

Workflow Map

The Workflow Map is a visual representation of the Workflow Lifecycle. The map displays the relationship between each Lifecycle State by using different colors to represent the type of Lifecycle State.

Color
Blue	Indicates the Entry point of the Lifecycle.
Orange	Is a Transitional stage of the Lifecycle.
Red	Indicates the Exit point of the Lifecycle.

Detailed information about a Lifecycle State can be accessed by clicking on the State field within the map.

Deleting a Workflow State

It may be necessary to delete a default State or a State that is no longer in use. Note that a State cannot be deleted if it has been assigned to a request.

To delete an unused State:

Select Service>Workflows
Click on the Workflow Name hyperlink
Click on the State Name hyperlink in the States Table beneath the Workflow Map
Click Delete
Select Save.
The State will be erased from the States list.