Show 

Home > Supervisor Guide > Service Level Management > Service > Workflow Tab

Incident Workflow

The default Incident Workflow defines the sequence of States to be followed by requests logged with the application.

 

When deployed, the system includes one fully customizable Incident Workflow for the Incident Management processes. This can be used immediately, or it can be edited to reflect more comprehensively your organization's support service requirements.
 

Configuring the Incident Workflow

The Incident Workflow can be configured to reflect the organizational Service Desk requirements for the Incident Management Process. The default Workflow includes States that are used by the business logic of the system to maintain control of the Incident 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 Workflow 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  Workflow. 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.

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 Incidents.

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.

* denotes the system-used States. 

 

Editing the Incident Workflow

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

 

If States are to be added or removed from the Workflow, it is advised 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 the Incident Workflow by:

  1. Select Service>Workflows
    The Workflows screen appears.

  1. Click the Incident Workflow hyperlink
    The Workflows tab appears. This tab is used to 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.

    Field Name

    Description

    Workflow Name

    Incident 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 State (i.e., where the Active State  option set to No). The option selected here determines the system behavior, regarding an inactive request, when an email is received from a Customer.

    • Do Nothing: Means the status of the request remains inactive, although 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 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 select the default Open State a request will move to after an email has been received from a Customer regarding a request in an inactive State.

    Description

    Defines the purpose of the Workflow

  1. Click Edit

  2. Amend details, as required

    hd_incident_workflow.png

  1. Click Save.

 

To add or edit Workflow States:

  1. Select Service > Workflows

  2. Select the Incident Workflow hyperlink
    The Workflow > Categories screen appears.

  3. Select the Lifecycle tab

  4. Click New

  5. Enter the Status details

    hd_incident-lifecycle_open.png

    Status

    Name

    System Defined States cannot have the name altered. For other statuses, 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 Incidents tab list view.

    Time Estimate

    Estimates the amount of time the request will be in the State.

    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 Webservices 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. When the option is set to No, the SLA timing is stopped while the Incident is in this State.

    SLA Restoration

    When timing is set using SLAs, 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.

    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 item in the Next Action field.
    (It is recommended that this step is left until all Workflow States have been defined)

    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 service request.
    (It is recommended that this step is left until all Workflow States have been defined)

  1. If editing a State, click Delete to remove the State entirely from the Workflow, or Name/Rename the State

  2. Enter all State information up to the SLA Resolution field

  3. Save the updated State details

  1. Continue to edit, add or delete States until all relevant lifecycle States exist for the Workflow

  2. Create the Workflow Lifecycle
    To assign 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.

  3. Assign a States to be a Next and/or Previous State
    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.

  1. Click Save to return to the Workflow map and to access other States to build on the Workflow Lifecycle

  2. Repeat Steps 9 to 11 until all transitional stages of the Workflow have been mapped

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

    incident_workflow.png

 

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

  1. Select Service>Workflows

  2. Click on the Workflow Name hyperlink

  3. Click on the State Name hyperlink in the States Table beneath the Workflow Map

  4. Click Delete

  5. Select Save.
    The State will be erased from the States list.

 

Questions to consider when editing the default Incident Workflow

The flexibility of the fully configurable Incident Workflow can at times provide a challenge for new installations and evolving support environments.

 

For new installations the default Incident Workflow is generally quite suitable, but as Users become more familiar with the application and look to adapt the Workflow Lifecycle to better reflect the organizational requirements, an understanding of the elements included in the Workflow and how they impact other parts of the system is needed.

 

When adjusting the Default Workflow, it is advised that the Supervisor User map the Workflow Lifecycle outside of the application and define all possible pathways through the different stages of the Lifecycle, before commencing the configuration process in the system.

 

After each stage of the Lifecycle is identified, then consideration needs to be given to the specific requirements of each Workflow State. These include:

 

status_notes_option.png

 

Is this an active stage of the Workflow?

If the request assigned this stage of the Workflow is to appear in the My Tasks filter for Technicians, (i.e., on their Home tab), then it should be marked as Active State: Yes.

 

The Active State flag implies an Open State, so anything in an Active stage of the Workflow will be included in the report results for Open requests. For example, Open Incidents by Priority or Open Problems by Age.

 

Requests in a Workflow stage assigned an Active State : No are, by default, not visible on the Home tab of Technicians and considered to be Closed from the perspective of the customer. This allows for follow up work to be performed that doesn’t concern the customer.

 

Is this an Entry Point or Exit Point?

If the stage of the Workflow is to be where the request commences its journey through the Workflow Lifecycle, it is an Entry Point and no Previous stages exist before this State. Once a new Entry Point is saved within the Lifecycle tab, it can be set to the Default Open Status within the Workflows tab.


default_open.png

 

If the stage of the Workflow is to be where the request ends it journey, it is an Exit Point and no Next stages can be assigned to it. This stage can also be defined as the Default Closed Status within the Workflows tab, after it has been created and saved within the Lifecycle tab.

 

If the stage is a transitionary stage of the Workflow, it is neither marked as an Entry Point nor Exit Point of the Workflow.

 

Are there special instructions that need to be followed when the request enters this stage of the Workflow?

If the answer to this question is yes, then it is advisable to check the Has Notes option. By doing so, a Notes tab appears, which allows the Supervisor User to enter instructions that will become available to the Technician User when a request moves into this stage of the Lifecycle.

 

incident_status_note.png

 

When a request moves into a Workflow stage with a Status Note, an icon is displayed next to the Status field in the request Information screen. Technicians can then view the notes by scrolling over the icon.

 

Workflows and Service Level Management

The next series of questions that need to be considered relate to Service Level Management.

 

hd_service_cont_wf.png

 

Is this stage of the Workflow to be measured by service level timers?

If Yes, set the SLA Active option to Yes,  and when a request is in this stage of the Workflow, time will be recorded and measured against the response, restoration and resolution targets for the Service Level Agreement applied to the request.

 

Warnings and escalations configured for the SLA will be activated when target triggers are reached by the time accumulated in a service timer Active State.

 

If the SLA Timers are active, has the SLA Restoration time been met?

If the SLA Restoration time for the Priority of the SLA applied to the request has been met when the request enters this stage of the Workflow, this option should be set to Yes. This ensures that automated warnings and escalations are deactivated in relation to the customer’s service being restored.

 

If the SLA Timers are active, has the SLA Resolution time been met?

If the SLA Resolution target for the Priority of the SLA applied to the request has been met when the request enters this stage of the Workflow, this option should be set to “Yes”. The SLA Resolution option within the Workflow State will ensure automated warnings and escalations will be deactivated in relation to the customer’s issue being resolved.

 

Building the Workflow Lifecycle

Once the specific elements of the Workflow State have been configured, you are ready to build the Workflow Lifecycle - that is, map where a request can come from, and where it can go to.

 

As mentioned at the top of this document, when configuring a new Workflow or adding new Workflow States, it is advised that all stages be created in the system before mapping  the Workflow Lifecycle. This will make mapping Previous and Next States a much simpler task.

 

previous_states.png

 

If this State is a transitionary State (i.e., not an Entry Point or Exit Point), where can the request come from when moving into this stage?

Using the Workflow that has been drafted outside of the system, the Previous States are easily configured by selecting the State(s) where the request can reside immediately before moving into the Workflow State being edited from the Available State list, and moved to the Selected States field.

 

If this State is a transitionary State (i.e., not an Entry Point or Exit Point), where can the request move to after this stage?

Using the Workflow that has been drafted outside of the system, the Next States are easily configured by selecting the State(s) where the request can move to immediately after the Workflow State being edited from the Available State list, and moved to the Selected States field.


next_states.png

 

The ability to move a request between two States can easily be achieved by assigning the two relevant States to the Available States list, within the Next States field for each State.