]project-open[ : @This Wiki
Portrait

Welcome, Unregistered Visitor

Contents

User Profiles

3 registered users
 in last 24 hours

]po[ Helpdesk

The Helpdesk package is an incident and change management system.  It can be used to keep track of interaction by clients and providers in Service Level Agreements (SLA), as a central place for client requests to be captured and starting point for the provider response and continual tracking until the request issue has been resolved.  These operations fall under the category of "ticket management", and the Helpdesk has a wide range of functionality, having the ability to closely track Incidents such as Bug or SLA Requests, or Change, such as Feature, Training, Purchasing, etc., Requests.

 

screenshot_helpdesk.gif

(Screenshot show a list display of all the Helpdesk "tickets" currently on the system.)

 

Configuring Ticket Workflows and Default Queues

Once a ticket has been created, the helpdesk checks information associated with the ticket type in order to determine:

  • The workflow to start for this ticket and
  • The default queue for the ticket.

 To configure the default workflow please go to Admin -> Categories and select "Intranet Ticket Type". Please observe the following two fields:

  • im_categories.aux_string1 - ticket workflow. If this field contains a valid workflow_key then the corresponding workflow is started for the new ticket.
  • im_categories.aux_string2 - default queue. This field serves to define the default queue for the ticket, if the user hasn't choosen a queue manually.

 

The logic that uses "im_categories.aux_string2 - default queue" and classifies a ticket is included in the PL/SQL procedure "im_ticket__classify". This PL/SQL routine should be called by the first Transition of the ticket's workflow.

Here is how you can check if im_ticket__classify is called for your workflow:

  1. Check the workflow_key for your ticket type in Admin -> Categories -> Intranet Ticket Type
  2. Go to Admin -> Workflows and choose the workflow that corresponds to the workflow_key.
  3. In the workflow page click on "graphical process editor".
  4. Click on the very first transition of the workflow
  5. Click on the (actions) link of the first transition.
  6. Please write "im_ticket__classify" (without the double quotes) in the field "Enable PL/SQL proc" and press "Update". All other fields can be blank.

 With this setting, now try to create a new ticket with a Ticket Type that is associated to your workflow.

 

Classifying Tickets

Classifying tickets in helpdesk operations refers to determining a type, a position in a global issue hierarchy and other operations.

In ]po[, this operation is implemented by the PL/SQL function "im_ticket__classify" which is located in the /packages/intranet-helpdesk/sql/postgresql/intranet-helpdesk-create.sql file.

You can take the existing im_ticket__classify as a template to add your own business logic. Withing the im_ticket__classify, you have access to all user specified information about the ticket plus information on the ticket environment such as the SLA, information about the customer etc.


Assigning Tickets to Queues and Users

In ]po[, there are many different ways to assign a ticket to a user or groups of users to provide you with maximum flexibility. Here are some of the options:

  • Assigning a ticket to a specific user:
    The Helpdesk provides an im_ticket.assigneee_id field that allows Helpdesk staff to assign the ticket to a specific person to take care of it.

  • Assigning a ticket to a "Queue":
    A queue refers to a specific group of people. You can create new Queues using profiles.
    The Helpdesk staff can either assign a ticket explicitely to a queue. As an alternative, the im_ticket__classify procedure can be used to assign a ticket to a queue, depending on context information such as the ticket type, the associated configuration item or other context information.

  • Using the Petri-Net Workflow:
    Sometimes a ticket needs to be processed by different "queues" during its lifetime. For example, a first "quote" stage could be assigned to pre-sales personal, while execution would depend on the type of ticket, and the customer himself should finally sign-off the ticket.
    In these complex cases you can use the full power of the built-in Petri-Net Workflow to configure your ticket workflows.

 


 

References

Maturity

  • Active and Stable

 

Related Tutorials

Related Object Types

Related Packages

Related Modules