3.Ticket management

Integria IMS proposes a vision of ticket management which adapts to different needs: a ticket can be understood as a technical problem, a change or configuration process, the result of a planned intervention, a software bug or a worksheet for a more complex issue. A series of common elements unite all these activities, for Integria IMS these common elements are references to other tickets, references to one or more objects from the inventory and the unique link that a user has with a ticket. All these concepts are covered on the good practices guide proposed by ITIL.

Plus, Integria adapts quite well to the Kanban methodology that allows managing the development as an evolutionary process based on process queues. To apply Kanban it's necessary to integrate ticket management with WorkUnits and project management.

Ticketing flow

An example of ticketing flow with Integria

Our support team has three members (Tom, Javier and Louis) and a team leader (Ramón).

We have different types of clients: those who work in the same team and those who operate independently.

Those who work in a “team” eg. a customer who has multiple persons working simultaneously and that 'see' their teammate's tickets either to contribute something, or to take care of them.

Those who operate independently can only see their items, and are the only people who can see it.

The first type of customer will have their own group along with users assigned to it, whose privileges are based on the profile associated with their workgroup. The second type, on the other hand, operates independently and can only see their “own items”.

When a customer that works in a group opens a ticket automatically, since the group is defined that way it's assigned to a generic Integria account called “Support”. Generating an email that goes to “[email protected]”. Both the default user and the email address are specified in the group configuration section.

This email account will automatically send a copy out to each member of the support team. That week, Javi's on duty, sees the email and clicks on the link to go to Integria. He'd see something like the following:

On Integria he sees a new ticket in red. The user who created it can be seen along with other data.

When faced with a new ticket, like the one in red, we can add the first. When a WorkUnit (or note) is added to a new ticket, said WU will be assigned to the user who writes the WU and its status is changed to “Assigned”.

By clicking on the ticket marked in red we enter the main screen for ticket management. We can change its status or browse its tabs to see its history, related notes (WorkUnits), files, etc. We're interested in replying promptly to the issue, considering that, from the moment the incident is opened, it calculates how much time it's left unattended. If the time margin established by the SLA associated to that ticket's group is passed, an alarm will go off corresponding with the name of the ticket, and an email will be sent automatically.

When a WorkUnit (note) is added or a file changes its status, an email notification is sent to all users “subscribed” to that ticket. In this case, Javier's going to place a note that says “I can see what you're telling me and I'll try to reproduce it to determine the origin of the issue”.

When the WU is created, the ticket changes status. The author of the ticket will receive a note that Javier inputted to the system.

Days go by and the problem isn't getting solved. Julian, the customer that created the ticket, asks about the issue again. That day, Javier isn't at the office. A workmate of his, Louis, in charge of tickets, sees that the ticket has been updated by the customer and sends a reply, adding another WU himself.

From that moment on he's subscribed to the ticket and will receive notifications on any change in the ticket. We can see on the left side menu the users that are participating in a ticket: the author, the user that “owns” the ticket (Javier) and those who've taken part in it.

A user with no “Management” permits on the ticketing system, but that those have writing permits, can add WUs but will not be able to “change” the ticket owner or close the ticket if they do not own it. If the user is a ticket “manager” then he or she can change the ticket owner. If the user is the ticket owner, he or she can “reassign” it to another user. This process is known as upscaling a ticket.

Finally, Javier was able to close the ticket. In the “Epilogue” field he wrote a summary to the problem's solution and changed the ticket's status to “Solved”. This way, “solved” or “closed” tickets cannot be seen in the main ticket view although, of course, they can be searched for if needed.

Ticket types

Ticket types allow custom tickets to be created for different groups, as well as allowing specific work orders to be included.

To create a ticket type there are two options:

  • the button below the ticket types list.

  • the ‘Create ticket type’ option that appears in the sidebar.

Definable fields in ticket type creation/editing:

  • Name: obligatory and must not be repeated, i.e. no two tickets may share a name. This is the field that is displayed in ‘create/edit tickets’ in order to select the type.
  • Description: optional field.
  • Template: optional. Allows a template to be added to a work order.
  • Groups: optional. Allows a type to be related to one or various groups. If left empty this kind of ticket can be assigned to any group.

Actions applicable to a type are:

  • Add custom fields.
  • Update information (name, description, template, groups).
  • Delete.

E.g.

To update, click on the wrench icon to go to edit view. You can modify any section from here.

To delete, click the trashcan icon. You’ll be asked to confirm. Once the action is performed it is definitive.

To add more custom fields click the ‘add’ icon.

Custom fields

In field creation you can define:

  • Name: obligatory field. Doesn’t have to be unique.
  • Display in ticket list: if you select this option it will appear as a column in the ticket list.
  • Global field: if you select this option it will appear in the ticket search form in advanced options.
  • Field type:
    • Text type: in the “create/edit ticket” form an input field will be displayed.

  • Textarea: in the “create/edit ticket” form a text area field will be displayed.

  • Combo box: in the “create/edit ticket” form a select form will be displayed where you can see all available options.

  • Linked: interrelated custom fields:
    • e.g., TYPE, VEHICLE, MAKE, MOTOR, MODEL
      • First, create the TYPE field. In this case, no parent field is selected because it is the first in hierarchy. Values are separated by commas.

  • Then create the MAKE field. In this case, select the parent field TYPE. After, fill out the field with the values separated by commas as in the previous example. Because this field has a parent, the values must be associated with it. To do this, first include the parent field value separated by |

  • Next, create MODEL field. Select the parent MAKE and input the values.

  • Finally, create MOTOR field.

  • Numeric: in the “create/edit ticket” form a numeric field will be displayed.

  • Date: in the “create/edit ticket” form a date field will be displayed.

A list with all the fields you created will be displayed.

The list is made up of the following columns:

  • Field name.
  • Field type.
  • Parent: exclusive to linked types as these can refer to a parent.
  • Value: exclusive to combo box and linked types as these have a selectable default value.
  • Actions: allow the field to be edited or deleted.
  • Ordering: to assign the order in which they are displayed.

Example of ordering: If you want the TYPE, MAKE, MODEL, MOTOR fields to appear first, and in that order, select the four categories from the list and in the ordering menu select the “before” option and the position (in this case, first position).

As can be seen, the linked fields appear at the beginning of the list.

Groups

Assigning a group to a ticket is optional and allows you to relate a type to one or more groups. If left empty, this kind of ticket can be assigned to any group.

E.g.

As can be seen in the previous:

  • example belongs to the Customer #A, Customer #B,, Engineering
  • example1 belongs to Customer #A
  • example3 belongs to Customer #B

Work order templates

A ticket can be associated with one or more work orders . A work order is a document that can be downloaded for subsequent validation . There are two templates to facilitate the document’s creation. A ticket type can only have one template associated with it.

Template creationa

  • ‘Create’ option that appears at the bottom of the list.
  • ‘Create work order template’ that appears in the sidebar.

Template elements:

  • Template name.
  • Description: optional.
  • Assign to: choose the ticket type that the template will be associated with
  • Content: plain text or HTML. To choose HTML click the icon in the toolbar.

Add images by clicking this icon:

Add the image’s URL.

The following words will be replaced on templates that use them with actual values:

  • _sitename_: As configured.
  • _username_: Of the person who receives the email.
  • _fullname_: Of the person who receives the email.
  • _incident_id_:
  • _url_: incident URL.
  • _creation_timestamp_: Date/time incident was created.
  • _update_timestamp_: Last time incident was updated.
  • _owner_: User responsible for managing the incident.
  • _group_: Group assigned to the incident.
  • _author_: Incident creator.
  • _type_tickets_: Ticket type.
  • _priority_: Of incident.
  • _status_: Of incident..
  • _resolution_: Of incident.
  • _time_used_: Total of incident.
  • _incident_main_text_: Description of incident.
  • Custom field templates:When creating an object type , the name of the included fields can be added as a macro displaying the value of said field: _customizable field name_..

These macros can be used in html code:

You now have a list with all the templates generated. Here you can see: name, description, what ticket type it’s assigned to, delete and edit.

Practical Applications of Tickets Types

Ticket types allow you to create tickets flexibly, i.e., when you select a type, the custom fields will appear and you can generate work orders using the template. E.g.

Select ticket type:

All the custom fields will appear:

Fill out the fields and create the tickets:

You can find a summary of the custom fields associated with a ticket on the Dashboard.

Work orders assigned to a ticket type

Use the ‘Work orders’ tab to manage work orders on a ticket

Click ’new’ to create a work order that you can then download, validate or delete.

Keep in mind that a validated work order can’t be deleted or downloaded. Only the validation itself can be downloaded here.

Ticket statuses

A ticket may contain numerous fields. The most important of these is probably the “Status” field. This field marks the status when a ticket, issue or change is considered to be finished, pending on a third party, new or recently created, if its assigned, if it's been reopened, if it's been verified or if it's been unconfirmed. This cycle is open to the user and can pass on from one user to another without default restrictions.

In case we want to define the flow, we have an option to Map statuses, on which we can define which status and solutions will be available to the user. Let's look at a practical example: we have a team responsible for managing client incidents. To ensure that the incident resolution order is respected and to comply with client SLAs, the map status indicates a ticket with “New” status can only go on to be “Assigned” or “Pending third person”: from any of these three states the ticket may only go on to “Pending closure”, and from there to “Closed”. Moreover, from “Closed” the only possible state is to return to “Reopened”. The configuration in this case will look like this:

An example of different ticket statuses

There are particular circumstances which act automatically when we change status. When changing status to “closed”, a text box will be automatically activated, which previously wasn't accessible, named “epilogue”. The epilogue carries the purpose of explaining the result of the intervention or change, or which was -in summary- the cause of the problem and its solution. As we'll see further along, a solved ticket is the basis for generating an article in the knowledge base that can be revisited on other occasions, in order to solve a problem in a quick and documented manner.

Users assigned to a Ticket

There exist five different roles on a ticket:

  1. Ticket Author
  2. Users responsible for a ticket
  3. Users with write permission (IW)
  4. Users with read-only permissions (IR)
  5. Users with management access (IM)
  6. User who closes a ticket
  7. User subscribed to a ticket

Ticket author

This user is the original author of a ticket. They assign another user responsible for that ticket (unless this is done automatically, as we'll explain further along), the ticket's group (which will also be explained) and other parameters such as priority, level of solution progress, description, linked inventory elements, etc.

The original author, once he or she creates the ticket, can no longer “command” it, so the user won't be able to close it until the parallel user responsible for said ticket decides to do so. The author also won't be able to reopen tickets.

Just like any user with access to the ticket, the author can add files and WUs.

User responsible for a ticket

He or she is the user assigned to the ticket, also known as the ticket “owner”. In the group definition a default user is assigned, depending on the selected group assigned by the author.

The ticket's author can change this user and choose another one belonging to the group to which the ticket was originally assigned. The ticket owner is the only one who can update the details or change the status on a ticket.

A user with management access (IM) over the ticket's group, can perform the same actions as the owner of a ticket, on all levels. He or she can manage (modify data on a ticket, change the owner, status, etc.) on any ticket inside a group where the user has been assigned an IM profile. When a manager changes the owner we say that a “manual upscale” has been performed on that ticket.

Users with write permission for a ticket

A ticket always belongs to a group. That being said, any user with the “IW” access flag can write WUs on a ticket. These WUs are like “notes” that stay attached to a ticket. This type of user cannot modify any other detail on the ticket such as status or priority, nor alter the main description for the ticket.

Users with read-only access to a ticket

Any user that belongs to a ticket's workgroup, and has the “IR” access flag, can read a ticket's details, although he or she will not be able to alter anything on the ticket nor add WUs or files.

Users with management access

A user with the access flag “IM” for a group where a ticket has been placed, can operate on it as if he or she were the owner. This implies being able to “upscale” the ticket, owning it or handing on the responsibility to another user. Of course said users can add WUs or files, and even close a ticket.

User who closes a ticket

This user is responsible for closing a ticket, although he or she is not the one to perform the action. For example, a user profile tagged 'technician' closes a ticket under command of an 'admin' user, In this case the user who closes the ticket would be 'admin'.

Users subscribed to a ticket

This can be any person “foreign” to the system. Their email is placed in the advanced option “additional email addresses”. If there is more than one to be added, they must be separated by commas. If said email address is part of the contact listing on the system, some of their basic data will be revealed such as name and company, or simply their email address.

On the “contacts” tab we can view the complete list of people participating in a ticket.

Ticket creation

To create and complete a ticket it's important to bear in mind the following:

  • What an Integria user is
    • Type of user (independent, normal)
  • What a group in Integria is
    • What relation does the group have with a user's visibility over the rest of Integria elements.
    • What relation is there between the group, the user access profile, and the type of user it's been defined as (independent, normal)
  • The inventory:
    • Contract
    • SLA

Understanding the difference between user groups and independent operators, their levels of visibility and their accounting of total tickets (soft limit and hard limit) is imperative. Remember that the following properties alter Integria's behavior when creating a ticket:

  • Independent user: independent users can only see their own reports so the group concept, profile and other elements aren't as relevant for this type of users. Independent users cannot change ticket properties that are set by default, such as assigned user or default object, since these are linked to the group.
  • Normal user: just like independent users, there are some ticket properties that are configured by default and cannot be changed. Items such as assigned user or default objects, since these are already linked to the group. Nevertheless, a user with management access (IM) will be able to change the status of the ticket or fields such as “original author” (so it doesn't repeat), or other aspects.

By default a new ticket will appear in “New” status.

There are some fields that are automatically assigned as “deactivated SLA” or “Automatic email notification”, which initially are linked to the default values that group has (the group to which the ticket has been assigned).These values, if management permissions are available (IM), can be altered. Otherwise, they'll remain with default values.

Ticket limitations

When creating a ticket there are two values defined on a group, as shown in the section on users and groups, that allow you to define how many tickets can be included in the same group (open or closed) for each user (total) and how many tickets can be simultaneously open for a single user from the group. A reminder on where this behavior can be configured:

If the soft limit is exceeded a warning dialogue will be shown on Integria although you'll be able to open new tickets (unless the “Force soft limit” option is activated). If the hard limit is exceeded it is not possible to open any new tickets associated with the group in question.

The limit to the amount of tickets is calculated by counting the number of tickets of the last year starting from the current date.  
The soft limit is calculated by counting the number of open tickets created in the last year.
The hard limit is calculated by counting the number of tickets of any status opened in the last year.

Normal user's view when creating a ticket:

Manager view when creating (or modifying) a ticket:

Creating the first WU

So, the ticket has been created by user “A” and has afterward been assigned to another user “B”. Now what?

When creating a ticket, the system will have sent an email to user A and another to user B, reporting on the ticket's creation. For user A this message has the purpose of confirming that the ticket has been registered by the system.

The user “B” can reply to that same email, which carries a special code, and send his or her first WU. The message can be something like “ticket received” or it can add extra information to the ticket. The user can also connect to the system using the URL administered to manually add a WU to a ticket.

When a ticket has “New” status it receives an automatic WU that changes its status to “Assigned”, which is a way of indicating that said ticket is being worked on.

Ticket operations

Once a ticket has been selected (or just after it's been created) we can operate on it both via the top and bottom tabs. Top tabs give access to ticket editing and allow the user to see or add attachments and notes.We can also return to the search results page.

On the bottom part we can navigate through the tabs that show ticket notes, files, statistics for that ticket, detailed tracking and the active ticket's contacts.

On this tab the tickets related to a main ticket can be seen, this means “child” tickets related to the main ticket that's being looked at which acts as a “parent” ticket. We must remember that when closing the parent ticket, all of its associated “child” tickets will also be closed.

Here we can see notes generated by different users, arranged from newest to oldest. From here we can directly add new notes.

Just like the Notes part (WorkUnits) we can see the attached files, download them, and upload new ones that we may find suitable.

This is the detailed view of a ticket that shows total times, time passed for each status and time dedicated by each person that's involved in a ticket, among other details.

In this section we'll be able to see the inventory objects related to a ticket.

Here we can see the details on people involved in a ticket.

Medals

Medals serve as quality control for our service. They measure the level of support we're offering. For this we can use gold medals when the support quality has been good, and black medals indicate that we're not satisfied with how the incident was solved.

To use medals activate "quick edit" mode. 

Users with quality control permits can add or remove medals for tickets (in the Quick Edit section):

In the ticket status column list the amount of medals of each type can be seen. Medals can also be used to filter the list according to medal types.

On the monthly report (“People” section from the menu) we can see the amount of medals that each Integria user has.

Furthermore there is now the possibility to add medals automatically to the workflow rules configuration (for example a black medal can be added to a ticket that hasn't been updated for a week or more).

Searches

Search view

Ticket searching is the basic control tool for tickets.

You can use the basic search view to look at the tickets you want, or access the ticket number directly on the left side menu. Default searches show all unclosed tickets and those that are unsolved. Searches show a list and basic statistic information on the results of this search. You can see, while in fullscreen mode, printable screens by pressing the option to generate HTML report view on the “Statistics” tab.

The advanced search is similar to the basic search, with the difference that it adds a multitude of additional search filters. Any search can be saved as a custom search, so that with the combination of custom search selection any previous search can be accessed. Custom searches are different for each user.

Click on a ticket to see the details. This will activate the upper tabs in the tickets section to see its details, the inventory of linked items, review changes, add workunits, etc. The environment is AJAX-based, which means it's not necessary to refresh the page. We can simply return to the search screen and access another ticket.

All columns on the ticket search view can be sorted automatically by clicking on the title. They can be arranged by: date, title, number of work hours assigned, group, status, etc.

Let's see the information that each row on the ticket list shows:

  • ID: the first column refers to the ticket's numeric code which can be used to directly access a specific ticket.
  • SLA: an exclamation mark to let the user know that a ticket doesn't comply with the SLA.
  • Ticket: the ticket's title. Underneath the ticket type will appear and custom ticket type fields will appear between brackets and marked to be shown on the main view.
  • Group: The group to which the ticket belongs. Underneath it is the name of the company to which the user who created the ticket belongs (whenever such information is available).
  • Status/Solution: the status (closed, assigned, pending on closure, new, solved and unconfirmed) and the solution level (solved, incomplete, “works for me”, expired, etc.).
  • Priority: marks different colors depending on ticket priority. Optionally, an icon, such as a note, can appear underneath the color tag like on the previous screenshot. This indicates that the ticket has a WU from the ticket's original author, which means that we should answer or that the “ball is in our court”.
  • Updated/created: indicates when the last ticket was updated and when it was created. If a username appears, it belongs to the person who created the latest WU on the ticket.
  • Author: shows the ticket author.
  • Owner: shows the name of the user assigned to the ticket, the owner and only user who can close it (except for users with more privileges: admins or managers).

Custom ticket searches

A ticket is a generic concept, like the word “ticket” itself, but this can be used to designate software failure (bug), a communications issue, or an issue involving a customer and his or her order. In one case there is a series of custom fields, and in other cases those fields will change accordingly. Because of this, the possibility to define custom ticket searches gives this flexibility. On the same system we can work with different ticket types.

All custom fields can be searched for when selecting the ticket type. A user can also save a custom search within the general search tool.

On a previously created ticket we can, optionally, change its type since there is a checkbox in the “setup” section used to define this behavior. If we do so, we lose the values on the custom fields for the previous type.

All custom searches can be reused on the general ticket view, apart from being the base data for any standard ticket reports.

Dashboard (Main view)

The dashboard is a view that allows the user to, from a simple glance, see tickets that are grouped and have direct access to previously configured custom searches. It's the default screen when we click on Tickets in the main menu.

Reports

This section allows us to write a report to which previously created, custom search values are applied.

In case no custom searches exist, a window will be shown to guide us to the search creation screen.

The report's content can be divided into two sections:

  • showing statistics
  • Showing a ticket list

If none of the options are selected, a reduced version of the statistics that contains the following graphs and charts can be seen:

  • Tickets per group
  • Top ticket authors
  • Top assigned users
  • Ticket statistics
  • Top 5 groups based on time
  • SLA compliance

If we select the option to show statistics we'll obtain, apart from the graphs and charts described in the previous view, some additional statistics:

  • Tickets per status
  • Tickets per priority level
  • Most active users
  • Top 5 most active tickets
  • Opened/closed tickets
  • Histogram of open/closed tickets
  • Ticket activity

When the option “Show list” is selected, we'll obtain the entire ticket list:

Click on the icon to export the report.

SLA management

The SLA is the way to “prove” that the ticket management is working under certain criteria. SLAs are managed automatically by Integria, that tests them periodically using a programmed task activated when Integria is installed.

The SLA is processed according to certain parameters:

  • Name: combinations to identify the specific SLA.
  • Enforced: makes the SLA send out emails when something is unaccomplished (enforced) or just warn the user with a bright indicator.
  • Base SLA: indicates that one SLA is related to another (only on an informative level).
  • SLA type: an SLA can be of three types:
    • Normal SLA: When making the calculation, it takes into account tickets that are not in Closed or Pending status.
    • Third party SLA: this takes into account those tickets whose status pends on third parties.
    • Both: This will take into account those tickets that have any status but 'Closed'.
  • Max. response time: indicates, in hours, the minimum response time that has to be respected when a Notification (new ticket or WU) is sent from the ticket author. When this time limit is exceeded an SLA will go off. For example, if it's 4 hours, and a new ticket has 4.1 hours of life, the SLA will go off. If, for example, it's an old ticket (1 week or more) and the last WU is from the ticket author and has over 4 hours of life, the ticket will also go off.
  • Max. solution time: it indicates, in hours, the maximum lifetime for a ticket. If a ticket has more time than initially defined and isn't close or solved, the SLA will go off.
  • Max # of simultaneously open tickets: indicates the total number of tickets that can remain open simultaneously. If there are more, the SLA will go off.
  • Max. amount of inactive time: Defines the maximum amount of time a ticket can remain inactive. When this time limit is surpassed an email will be sent to the person assigned as responsible for the ticket to remind him or her that the ticket is open.
  • Start time for SLA activation: time from which the SLA starts to be calculated (for example: 9:00 AM).
  • End time for a SLA:time from which the SLA is no longer calculated (for example: 6:00PM).
  • Disabling SLA on the weekend: if this option is marked on the SLA it only calculates weekdays, excluding weekends.
  • Disabling the SLA on vacations: if this option is marked on the SLA it won't calculate days defined as vacations.
  • Description: informative text used to describe the SLA.

What does it mean for the SLA to "go off"?

It means that the system will send an email notification to the ticket owner, advising that the ticket isn't complying with parameters established on the SLA to which the ticket belongs. A ticket can be tied to different SLAs simultaneously, if it's related to different inventory elements. An SLA that has already gone off won't deactivate by itself just because, for example, it's the weekend. This means that any tickets that don't comply with an SLA, until all their conditions are met, won't return to “normal status”.

We can see the historic evolution for a ticket's SLA compliance, or the total compliance values in general reports. A low SLA will generally mean that the ticket hasn't been managed correctly. It's a commonly used indicator to offer summaries on the quality of ticket management.

When an SLA goes off a lit indicator will appear on the ticket view.

Let's see an example of SLA definition:

SLA's are linked to ticket status. This means that if the chosen type of SLA is Normal the SLA won't apply for those tickets that are in either Closed or Pending on third party status. If the type chosen is third party SLA the SLA will only apply for tickets that are pending on third parties. If Both are chosen the SLA will apply for all tickets except those with a Closed status.

SLA based ticket evaluation

Using the SLA system on a ticket's tracking report we can see, on a time scale, when a ticket hasn't complied (marked in red) and when it has (marked in green). Plus it includes % markers on the ticket's compliance throughout its existence.

Workflow rules

This is an Enterprise feature meant to define custom rules as applied to ticket management. This means that when a ticket that isn't closed complies with any condition associated to a rule, certain predefined actions are performed. For example: when a ticket from the Support group has been left unattended for 48 hours or more, an email is sent to the user responsible informing on the situation.

These rules can only be defined and managed by “super-administrator” users. The rules will be applied a single time. An exception to this are rules that take into account a ticket's update date. In this case the rule will be launched accordingly whenever an update is performed.

Workflow rule management

Rules have a description field that helps to identify their behavior. In the screenshot below a list of system-created rules is shown. In this case, we have a rule to add WUs and send an email to the person responsible when the ticket has remained unanswered for 48hs.

Each rule has conditions related that must be complied with to perform the actions. If a rule has more than one condition, all conditions for the action to go off need to be met. To be able to modify the rule or access its conditions and actions you'll have to click on the description. In the editing section apart from the description we can choose “Run Mode”:

  • Cron: this will check every x amount of time (default 5 minutes) if the workflow rules are being followed.
  • Realtime: checks immediately if workflow rules are followed.

Workflow rule conditions

If you click on the “Conditions” tab, you access the list where you can define in which cases the rule will be applied. In our example we have a condition that is already defined. We can have one or more conditions per rule. In case we have more than one, once one of them is met the rule will automatically activate and run the action or actions that have been programmed as a response. Conditions are composed of a group of filters or “subconditions” which are described as follows:

  • Condition: how conditions will apply to the rest of filter fields, all within the condition's definition (whether all, some or none coincide in all fields).
  • Owner: user responsible for a ticket
  • Priority: A higher priority doesn't engulf lower priorities.
  • Update date: time elapsed since the ticket was last updated.
  • Text to search for in the title or description of the incident: works for a string inside the WU, the title or the description.
  • Task: Task associated to the ticket.
  • Ticket type: by selecting the ticket type custom fields will appear and we can make use of them to add them to the group of filters for this “Condition”.
  • Ticket Group
  • Ticket Status
  • Creation date: Time passed since creation.
  • SLA: If the SLA was triggered or not.
  • Ticket Solution.
  • SLA compliance (%): a ticket's SLA compliance percentage.

In this example condition we've defined the characteristics a ticket must comply with. The group has to be “Support”, the priority “Medium”, and the status “Assigned”. The condition field chosen is Coincide with all fields because we want all of them to be fulfilled.

Workflow rule actions

Next let's look at the actions that will be performed if previous conditions are met.

Actions are composed of the following fields:

  • Description
  • Action type: possible executable actions.
  • Variable: additional fields will appear depending on the chosen action, eg. a text field for the action of adding a Work Unit.

Actions are defined according to the “Action Type” field:

  • Change priority
  • Change owner
  • Change groups
  • Change status
  • Send email: “For”, “About” and “Text” are the fields that appear.
  • Add a WU: the WU's text will be added to the instance along with the user specified.
  • Change update date: modifies the date on which the ticket was last updated.
  • Change solution: updates the value for the ticket's closing solution.
  • Execute command line: allows execution of a custom command including macros for dynamic variable replacement such as ticket ID, group, user, etc.
  • Ticket Lock: field values on a ticket can't be modified.
  • Ticket Unlock: the values on ticket fields can be modified again.

When creating the first action a default action is created which replaces a ticket's previous update date with the latest one. This action can be manually deleted on the actions list.

Examples:

  • “For any instance in the “Customer” group that has remained over 10 hours without being updated, an email is sent to the ticket's owner. The email's body will be something like this “The instance (title) on the Customer group is being left unattended. Review this subject immediately”.
  • “For any instance that has been open for over 21 days, and is under “High” priority, its priority will change to “Medium” and another WU is added that says “automatically reprioritized by the system”.

In general workflow rules can only be triggered once. This means if a rule is scheduled for change, a user X assigned to this instance -when said instance is over 30 days old- can be changed manually. If someone places that same user manually, the rule won't be triggered again.

The only exception to this behavior is when the condition is update time. If a rule is set up to go off when the ticket has remained more than x amount of time without updates an automatic default action will be created to “Update the ticket”. This means that the condition won't go off constantly. Once x amount of time has passed the system will be able to perform the same WorkFlow rule. This is the exception considering that for no other condition (Priority, Ownership, Status, Creation or Group) will a rule be executed again.

A typical example case for this type of condition:

  • “ You need to send a warning email to a coordinator as soon as a “very high” priority instance from a specific group has been left unattended for over 5 days (no updates).“

Simply the condition “Coincide with all fields” along with the specific group and the -in this case- very high priority all need to be marked, all for assigned instances. In the “Update date” field a specific week is chosen.

When adding a command to send an email, a ticket update command will be automatically created, which we will leave as is, in order to update the ticket and avoid the rule from being overridden constantly.

MACROS

The subject and body of the email can be placed using macros. Below, all available macros are detailed:

  • _incident_id_: ticket ID.
  • _incident_title_: ticket title
  • _creation_timestamp_: time and date of a ticket's creation.
  • _id_group_: ID for the group assigned to a ticket.
  • _name_group_: name of the group assigned to a ticket.
  • _update_timestamp_: indicates the last time a ticket was updated.
  • _author_: ticket author (creator).
  • _owner_: user who controls a ticket.
  • _id_priority_: an instances priority ID
  • _name_priority_: name of the instance's priority.
  • _access_url_: a ticket's access route.
  • _sitename_: the name of the site as has been defined in the setup.
  • _fullname_: entire name of the user who receives the email.
  • _username_: name of the user who receives the email (just login name).
  • _id_status_: instance Status ID.
  • _name_status_: instance status name.
  • _id_resolution_: instance solution ID.
  • _name_resolution_: instance solution name.
  • _incident_epilog_: ticket epilogue
  • _incident_closed_by_: user who closes the ticket.
  • _incident_own_email_: owner user's email address.
  • _incident_group_email_: email address for the assigned group.
  • _incident_auth_email_: authoring user's email address.
  • _owner_: user who manages the instance.
  • _id_group_: group ID assigned to the instance.
  • _name_group_: group name assigned to the instance.
  • _type_tickets_: ticket type.
  • custom field templates: this allows users to use ticket type custom fields. The name of these added custom fields can also be included as a macro which shows the value of said field. The format is: _custom field name_.

This would be an example of executing a custom command:

Ticket creation via web form

Via Integria IMS' API REST it's possible to create new tickets. Using this feature we can develop custom forms that will allow us to register new tickets on the system.

The following PHP code creates a form and retrieves data sent by the form. With them it creates a call to Integria IMS' API that creates a new ticket.

custom_form.zip

To test it, copy this content on a text file, edit it to include the parameters on your installation and place it on the Integria console directory (set by default to /var/www/html/integria), and make a call using the browser to: http://localhost/integria/formulario.php

The resulting form should look something like the one below:

ticket48.jpg

Next, we'll add a commentary to part of the code. Remember to adapt these lines to your installation:

$integria_url = "http://inna.lab.artica.lan/integria";
// user and password for which creates the incident
$user  = "admin";
$integria_pass = "integria";
// integria api pass
$integria_api_pass = "1234";

The following variables configure general ticket settings. In this case it's the ticket's title, group, priority, description, body or otherwise.

	// Extra - status - new
$ticket_status = 1;	

// Set default parameters
$priority  = 0;
$inventory = "";
$type      = "";
$mail      = "";
$owner     = "";
$parent    = "";

$title = $_POST["title"];
$group = $_POST["group"];
$description = $_POST["description"];

//Get post parameters
if (isset($_POST["priority"])) {
	$priority = $_POST["priority"];
}
if (isset($_POST["inventory"])) {
	$inventory = $_POST["inventory"];
}
if (isset($_POST["type"])) {
	$type = $_POST["type"];
}
if (isset($_POST["mail"])) {
	$mail = $_POST["mail"];
}
if (isset($_POST["owner"])) {
	$owner = $_POST["owner"];
}
if (isset($_POST["parent"])) {
	$parent = $_POST["parent"];
}

In order to locate the IDs of the elements we need, for example the group ID (which is a mandatory field), we can access the corresponding group within Integria to see the ID on our browser's address bar.

ticket49.jpg

Next, a text string is created with the URL utilized to create tickets via the Integria IMS API. Apart from the server address and the username, configure the OP parameters with the value create_incident that indicates the API feature that'll be used, and 'params' with the function's parameters.

$myurl  = $integria_url."/include/api.php?user=".urlencode($user)."&user_pass=".urlencode($integria_pass)."&pass=".urlencode($integria_api_pass);
$myurl .= "&op=create_incident&params=".urlencode($title).",".urlencode($group).",".urlencode($priority).",".urlencode($description).",";
$myurl .= urlencode($inventory).",".urlencode($type).",".urlencode($mail).",".urlencode($owner).",".urlencode($parent).",".urlencode($ticket_status).",,,,";

Remeber: this URL is built for an API with IP authorization. If you're using password authorization on our API, the corresponding URL must be built by using $myurl = $integria_url.”/include/api.php?user=“.urlencode($user).”&pass=passAPI“.”&op=create_incident.

Lastly, the code makes a call on the Integria IMS API via the PHP CURL utility.

// Configure curl
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $myurl);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);

// Send curl request and close
$ret = curl_exec($ch);
curl_close ($ch);
$_POST = array(); 

If the mandatory fields are left unfilled (Title, Description, Group ID and Priority) it won't allow the ticket to be created.

Ticket Management via email

Integria allows creating and updating tickets by sending emails. This is an Enterprise feature

Depending on the email client used, the email format may differ. Integria's email management has been validated on the following mail clients: Evolution, Gmail, Outlook and Mail. 
Ticket and WU creation via email uses the same ACL principles as the GUI. 
You can access these principles in the "Users and Profiles" section. 

Ticket management using email is based on managing email queues, configured for each existing group in Integria IMS. You are required to configure email parameters as specified in the “Email setup” section.

Creating a ticket via email

Let's suppose you have the following email address enabled for mail reception: [email protected] and you've configured a group's “Email Queue” parameter with the following information:

[email protected]

We'll send an email with the following data:

  • From: <Integria user email address> (Optional: if the user doesn't exist, it will be created automatically)
  • To: <mailbox configured for POP in Integria>, <email queues' adresses>, …
  • CC: <other adresses in copy>
  • Subject: <ticket title>
  • Body: <ticket description>
  • Attachment: <files attached to the email>

Case studio:

  1. Once the email has reached the inbox at [email protected], it'll be checked for correspondance with any adress configured in the parametere 'Email queues'.
    1. If it can't find any correspondance with 'Email queues', the message is discarded.
    2. If it finds a correspondance with 'Email queues' then the default parameters configured for that queue will be used to manage the ticket (default ticket status, ticket type, associated company… etc.)
  2. If it coincides with a valid address, the application will process the message. At this point two things can happen:
    1. The email doesn't correspond to any current tickets. In this case a new ticket will be created.
    2. The email corresponds to a previously created ticket on the system. In this case a new WorkUnit will be created and ticket data will be updated.
  3. In order to create a ticket the following parameters need to be configured:
    • Author: this will correspond to the user whose address was in the “FROM” field of the message. If the user doesn't exist, it'll be created (only if this option is enabled in the 'Email queues' configuration).
    • Editor: this will use the same user corresponding to the “FROM” field of the message.
    • Group: the group that corresponds to the email queue.
    • Owner: the user related by default to this email queue.
    • Title: the “Subject” field from the email.
    • Description: the email body.
    • Email notifications: In this field of a ticket all email addresses apparing on the “TO” and “CC” fields that don't correspond with the address found for the email queue. In this example the following addresses will be used: [email protected], [email protected], [email protected]
    • Ticket files: any attachments on the email will be added.
  4. If the ticket exists on the system, then the content of the email body will be added as a WorkUnit and necessary modifications on ticket status will be made.

The following image summarizes management flow on email queues:

Adding a new workunit

If you have activated the notification sending system (Tickets section within Configuration), emails will be sent notifying you of the ticket changes. Simply replying to these emails will add a workunit with the content of that response.

As we see in the example, the notification email has been answered with “Thanks. Please close the incident all its ok. Javi” and the corresponding workunit has been created.

Just like ticket creation via email, WU creation adds files attached to the email to the corresponding ticket.

Ticket updates and WU customization

Integria allows users to modify tickets using emails by adding the following structure to a message's body.

[INCIDENT]
GROUP: IT
ASSIGNED_TO: dario
PRIORITY: 3
STATUS: Assigned
RESOLUTION: Invalid
[INCIDENT]

Fields and their possible values are as follows:

  • GROUP: name of the group to which the ticket needs to be moved.
  • ASSIGNED_TO: short name of the user to which the ticket belongs. This is the name the user has to login to Integria.
  • PRIORITY: priority at which the ticket changes. The priority is a number between 0 (lowest) and 5 (highest).
  • STATUS: name of the status to which the ticket will be changed. The status names are defined on the “Tickets” tab in the General Configuration.
  • RESOLUTION: name of the solution to which the ticket will change. Status names are defined on the “Tickets” tab in the General Configuration.

It's also possible to modify certain parameters in the creation of a WorkUnit using the following structure in the email body:

[WORKUNIT]
TIME_USED: 0.05
[WORKUNIT]

Fields and their possible values are the following:

  • TIME_USED: time dedicated to the WU. It's a decimal number separated by periods. By default the value for this parameter is set at 0.25 hours.

It is very important to verify the correct syntax of the previous structures, since an error in the headers or parameters can lead to an incorrect detection of the policies and changes will not be applied. In that case, they will be treated like any other text and will appear as a new workunit associated with the ticket.

Masking email addresses on WUs

It is possible that when you create a workunit via email, an email address will appear in the body of the message. This can occur, for example, when using the 'respond to all' function. If this information is considered sensitive and preferred not to appear in workunits, Integria allows you to mask email addresses. In this way, it is known that there was an e-mail address there, but you will not be able to guess which one. You can configure this option in the Ticket tab of the General Application Configuration by checking Masking email addresses. When this box is checked, Integria will change all email addresses to [email protected]

Incidents import from CSV

The import can be done by an export made in Integria (in which the structure as it is generated in the system shoud not be manipulated) and it can be done by a CSV file.

For the first case the input file will be the same as the one we previously exported, so it does not impose problems when processing the CSV.

For the second case a series of parameters must be entered in order, some required and some not, being able to choose empty values for the latter. The fields will be the following for the logical order established by the tool:

*Begin *Close *Title *Description *User id *Status *Priority *Group id *Update *Creator id *Task id *Resolution *Epilogue *Parent id *SLA disabled *Affected SLA id *Incident type id *Score *Email copy *Editor *Group creator id *Last stat check *Closed by *Extra data *Extra data 2 *Blocked *Old status *Old resolution *Old status 2 *Old resolution 2 *Extra data 3 *Extra data 4 *Black medals *Gold medals *Custom fields: must previously exist in your Integria IMS system and must be indicated in order, being able to choose a value, or in case of not wanting to give them value, blank space. In the case of tickets it will be necessary to create the type to which the fields belong and obviously to reference that type in the ticket itself.

Example

“2017-07-20 13:38:39,0000-00-00 00:00:00,Ticket test,,admin,New(ID),Medium(ID),Customer #B(ID),2017-07-20 13:38:39,admin,0,None,,,0,0,1,0,,admin,Customer #B(ID),0000-00-00 00:00:00,,,,0,1,0,0,0,,,0,0,Integria,20”


Integria Documentation