Integria IMS uses a ticket management system or 'ticketing' system. It can be used on software development projects as a helpdesk tool, or it can be adapted to your needs to tend to any customer or user interaction necessities. A series of common elements unite all of these activities, for Integria IMS those common elements are references to other tickets, the references to one or various objects from the inventory and the unique link of a user with a ticket.
Let's suppose our support team is comprised of three people: Tom, John and Louis, and a team leader Raymond. We have various types of customers: those who work on the same team and those who are “freelance”. Those who cooperate on the same team, which means, a customer that has various employees simultaneously working, can also see the tickets from their workmates, either to add productive content or take over the task at hand. Those who freelance can only see their own and they're the only ones who can see it. The first type of customer will have its own group, and users assigned to this group. Meanwhile, the other type of customer will belong to the “general” group and will have the “external mode” bit activated. This way, even if the customer belongs to a group, he or she will only view “their own items”. When a customer that works within a group opens a ticket, automatically, since this group is defined that way, a generic Integria account named “support” is added, also generating an email account that leads to “[email protected]”.
This email account automatically sends a copy to each of the support team members. That week John is “on duty” so he wil be the one to check the emails and click on the link to access Integria. He would see something like this:
In Integria IMS he will see a new ticket marked red. You can also see the user who created the ticket along with other data. When a new ticket is created the first answer for it can be added. When a Work Unit (or note) is added onto a new ticket, said note is assigned to the user who writes the workunit, and his or her status will change to “assigned”. Clicking on the red ticket, we enter the main ticket management screen. We can change its status, or navigate across ticket tabs to look up its history, related notes (or workunits, attached files, etcetera. A first reply is always desired as soon as possible, since tickets measure how much time they remain unanswered. If the established margin by the SLA associated to that ticket's group is surpassed, an alert will go off. When a workunit (note) or a file is added or changes its status, an email notification is sent to all users “suscribed” to said ticket. In this case, John will add a note that says “I can see what you're saying and I'll try to reproduce it to determine the origin of the issue”.
When the WorkUnit (WU) is created, the ticket has changed status. The author of the ticket should also receive the note John has added to the system.
Days go by and the problem isn't solved. Jules, the customer who created the ticket, inquires about this subject again. That day John isn't at the office. A workmate of his, Louis, who is in charge of tickets, sees that the ticket has been updated by the customer and proceeds to answer him, adding a WorkUnit himself. From this moment on he is subscribed to the ticket and therefore will receive notifications for any change the ticket goes through. On the left menu, the users participating in the ticket can be seen (in order): the creator, the “owner” user for the ticket (in this case John), and those who have participated in it.
A user without “Management” permits within the ticket system -but that does have writing permits- can create WorkUnits but cannot change the roles within the ticket or close it, if he or she is not the “owner”. If they are a ticket “manager” they can change the ticket “owner”. If the user happens to be the owner of the ticket, ownership can be reassigned to another person. This process is known as scaling a ticket. Finally, John was able to close the ticket, he filled out the “epilogue” field with a summary of the solution applied and changed the ticket status to “Resolved”. This way “solved” or “closed” tickets will no longer be seen in the default ticket view, although they can be searched for and accessed if needed.
It's very important that we first know what permits we have been granted for tickets. There are various different roles within a ticket:
The original author of the ticket. The creator will establish who is responsible for this ticket (unless this process has been automated), the group that said ticket belongs to (same applies in case of automation), and other parameters such as importance, how far along the solution is, description, inventory elements it's linked to, etcetera. Once the original author has created a ticket he can no longer “govern” it, this means he or she cannot close it until the user responsible for the ticket doesn't decide to do so. The author won't be able to reopen it either. Just like any user with access to the ticket, the user who created it can add files and WUs.
The owner is the user assigned to the ticket. During group definition, a default user is added, based on the group selected by the user who created the ticket. The ticket creator can change this user and select another belonging to the group to which the ticket is assigned. The user responsible for the ticket is the only one who can update its details or change its status. When a “manager” changes the user responsible for the ticket we say that there is “manual scaling” involved in that ticket.
Any ticket always belongs to a group. All users with the “IW” access flag can write WUs on a ticket. These WUs will act as “notes” that remain attached to a ticket. This type of user cannot modify any other ticket details such as status or level of importance, nor can it alter the ticket's main description.
Any user which belongs to a ticket's workgroup and has the “IR” access flag will be able to read ticket details, but will not be able to modify anything nor add any WUs or files.
An user with the “IM” access flag within the group to which a ticket belongs is able to operate over it as if he or she were the owner. This means that this user can «scale» the ticket by taking over it or passing its management on to another user. Of course these users can add WUs and even close a ticket.
These users are responsible for a ticket being closed, although it may not be the same user who executes any other action over it. For example, the “technical” user can close a ticket because the “admin” user gives the order to do so. In this case the user who closes the ticket would still be “admin”.
This is any person who is “foreign” to the system. His or her email can be added to the advanced option “additional email adresses”, if there is more than one, they are separated with commas. If said email is part of the system (within the contacts system) some of its data can be seen -such as name, company- or if not simply the email adress will appear. In the “contacts” tab we can see the complete list of people that take part in a ticket.
Up next we will see the main options that we can do with Integria's ticket system.
Before creating a ticket it's very important we know about different ticket types. Types can be assigned to tickets. Each type of ticket can have various custom fields associated, depending on what's needed. These fields can be of various types: text, combo, area text, numeric or linked. If we choose combo or linked types, we'll hace to specify the values these controls will have. Up next we can see an example for a combo type ticket:
We now can create a custom field associated to the previous type:
Fields with a checkmark where it says “Show in general view” are fields that can be used for searches and that are shown in the list view. In the fields with a 'textarea' type we cannot use this checkbox. General view:
Now that we have a slight notion of our users and customer types, we're ready to create our first ticket. We're going to follow these steps. Click on the overhead 'Support' menu → 'Tickets', after go to the left part of the menu and click on the 'create ticket' button. Here you'll be able to fill out all the high incidence information, assign the ticket, give it a priority, attach files, etc.
Now, we have a ticket created by an user (we're going to name it A) and another user (call it B) has been added. Now what do we do? When creating the ticket the system will have sent an email to user A and another to user B, informing on the creation of the ticket. This message will serve user A this message serves as a confirmation that the ticket has been added into the system. User B can reply to that same email, that carries a special code attached, and send out his or her first WU. It'd be something like a reply saying “I've received the ticket”. User B can also connect to the system with the URL given, in order to manually add a WU to the new ticket. At the time in which the ticket with a “New” status is assigned a WU, its status will automatically change to “Assigned”, which is a way of saying that someone has started working on the ticket. Independent from the way in which the WU is added, we can always review it in the ticket details by viewing the “comments” tab.
Ticket searches are the basic tool for ticket control and organization. The basic search view can be used to find the tickets we want or to directly access the ticket number on the left side menu. Default searches will show all unclosed and unsolved tickets. Searches provide lists and basic statistic information on the results prompted. In the left side menu we can click on “search tickets”. On this page we'll be able to see the tickets which we can access, as well as having the chance to filter them according to different parameters such as status, persons responsible, date, etcetera.
A ticket is a generic concept, therefore it can be applied to software failures (bugs), communication problems or even customer-order related issues. In one case it'll have a series of “custom” fields, and in other cases those will vary. Because of this, the possibility to define custom ticket searches allows us to keep this flexibility where we can save a section using specific search filters. For these in the “Ticket Search” section of the menu, we first filter out those fields we need and we click on the custom search button. Afterward, we can name that search and save it under Custom Search so we can use the same filters for further searches.
Custom Searches can also be used as a source for ticket reports. If we click on Reports on the left side menu, we can access the section where we can use one of those previously saved custom searches and view it on screen or save it as a PDF file.
This option allows defining custom rules that'll be applied to ticket management. This means that, when a ticket that isn't closed complies with a condition associated to a rule, some predefined actions are carried out. For example: when a ticket from the Support Team hasn't had a response in 48 hrs, the responsible user will be informed via email about this situation. Each rule has associated conditions that must be met in order to trigger the actions that've been defined. If a rule has more than one condition, all conditions must be met for the action to be triggered. In order to access these we must had admin credentials and later go to the left hand menu and select Workflow Rules. In order to modify the rule or access its conditions and actions, we have to click on its description.
In this example, on the Conditions tab we've defined the characteristics the ticket must comply with. The group must be Support, the priority is set to 'Medium' and its status 'Assigned' The chosen condition field will be “Match All Fields”, since we want all to be met. If we only wanted some to be met, the condicion field chosen would be “Match any field”, and if we wanted none to be met, the operating condition should be “Not Match”.
Below, in the Actions tab, we can see the actions that would trigger if the previously set conditions are met.
Some examples of this in use:
Integria allows creating and updating tickets using regular email exchanges. This is a feature that allows ticket management to be more agile, using your regular email client.
Ticket and WU creation via email uses the same ACL principles as the graphic interface.
Internally, ticket management via email works in the following way:
Suppose we have enabled the following address to receive Integria emails: [email protected] and also, we've configured the parameter called'Email Queue' from a group with said email address. Also, we'll send an email with the following data:
The following image explains the management flow for email queues in a summarized way:
In order to create a new ticket via email you only have to send an email to the configured mailbox and also, that it coincides with an email queue configured on the system. The email parameters must be:
An example of an email that would create a ticket would be:
This email will create a ticket just like the one on the image below:
Furthermore, if files are attached to the message, these will be added automatically.
If you have the email sending system to keep up with updates on Integria tickets activated, you'll receive emails with all the news on your tickets. On some of them you'll see that the title has assigned a ticket ID, responding to these emails can add new WorkUnits to the corresponding tickets. In some of them you'll see that the title has a ticket ID assigned. Replying to these emails can add new WUs to the corresponding ticket.
To add a new WU you only need to reply to the email adding the contents of the WU to the body. As a result, a new WorkUnit will appear on the ticket. If, for example, you reply to the email with the following body text “Thanks. Please close the incident, everything's OK. Javi” a WorkUnit like the one below will appear.
Just like email ticket creation, WorkUnit creation adds attached files on the emails to the corresponding ticket.