Asset infinity provides this functionality where a user working in an organization can create tickets in the asset infinity application by sending an email to a general E-Mail ID. In fact, the tickets can be raised to a particular group of user responsible to resolve the particular issue type.
Initially, the Ticket Groups, Priorities, and Ticket Types are required to be mapped properly before you wish to trigger tickets through emails.
Apart from the specified mapping above, users need to map certain attributes to set up the generation of tickets through emails.
Location: A location mapping helps the system to directly find the user group responsible for the issue being raised.
Ticket type: Ticket Type helps to determine to which user group ticket needs to be assigned.
Priority: Depending upon the location and ticket type, priority can be assigned to the ticket.
Managing Ticket Group
While you scroll down on the page you can see a grid where all the user groups are displayed and a column reflects the forwarding email that can be used to trigger tickets in the system. This forwarding email can either be directly used or can be configured onto an email account. Which can be further used to create tickets.
For example, there is an IT Department Group responsible for resolving IT related issues. Now, a general ID says IT@xyzorg.com has all his email being forwarded to this Forwarding Email. Whenever a user from the mails on IT@xyzorg.com a ticket gets raised in the asset infinity application.
There are certain rules that this functionality follows:
- The user creating the ticket or updating the ticket should be added as a user in the application.
- The user raising a ticket needs not to be part of the user group.
- All replies/remarks/updates are to be made on the email trail being followed for the particular ticket.
- Users that are kept in CC while generating an email triggered ticket can also update the ticket remarks whether they are the part of the user group or not.
- A person who is part of the email but does not exist as a user in the application cannot update the ticket.
Steps to follow as in actual scenario,
- A user group is created and users are added to this group with all binding of location, Ticket Type, and priority.
- A user (who’s email ID should be added to the application in prior) drops an email on the FORWARDING EMAIL, here we will also be keeping a user in CC who will not the part of the user group.
- A new ticket gets generated in the application. The subject of the email gets filled into ticket description and the Body of email is shown in ticket history’s remark section.
- Now, this ticket can be updated,
- If some user from the same user group replies over the email.
- The person marked in CC (user with email must exist in the application) replies in the same email thread.
Someone who is not part of the application, replies to the same email thread (Maybe Kept in CC) then there will be no update on the ticket.