Using E-Mail Commands to Create and Update Work Orders in Service Hub

E-mail Command allows the technician to delimit fields in the e-mail, according to which the e-mail can be parsed and corresponding fields can be set. 

E-mail subject must contain: @ITSM-update@ 

Sample email-content 

@@OPERATION=AddRequest@@ 
@@GROUP=Banner Administration@@ 
@@TECHNICIAN=Tim LaLonde@@ 
@@REQUESTTEMPLATE=Banner - Student Information System (SIS) request@@ 
@@CATEGORY=Student Information System (SIS)@@ 
@@SUBCATEGORY=Banner General@@ 
@@ITEM=Production Support / Problem@@ 
@@MODE=Email@@ 
 

Notes 

• A request can be created / updated / closed / picked up by a technician through e-mails. Operational strings used for these purposes are 
  • Operation = AddRequest 
  • Operation = EditRequest 
  • Operation = CloseRequest 
  • Operation = PickupRequest 

• To update, pick up or close a request through e-mail, the corresponding operational string (EditRequest / PickupRequest / CloseRequest) and the RequestId must be present. If not, the e-mail will be processed normally and treated as a new request. 
• When a request is updated through an e-mail, the conversation will not be added in the request. Hence attachments and inline images in the e-mail will not be updated in the request. However, the update information will be added in the history. 
• If the field name given in the e-mail is not available in the application, then parsing will be excluded for that field. 
• If there is more than one value present for a particular field in an e-mail, then the last value alone will be taken and others will be discarded. 
• Request threads with subject containing the "RequestId" and no operational string (EditRequest) will be updated as a normal conversation and a new request will not be created. 
• The e-mail sender should have a login in the application for the E-mail Parsing to happen.  This is because, various operations that can be handled by a user to parse an e-mail are defined by the user's Role. Request authorization (close a request, pick up a request, update a request, accept closure of a request and so on) are set using Roles in the application. 
• The email should be sent in plain text rather than HTML. Special characters in passed parameters can cause issues and lead to inconsistent results when sent via an HTML formatted email. 
• The e-mail sender will be considered as the requester if the requester name is not specified in the e-mail. 
• Permissions and Parameters supported: 

1. • If the e-mail sender is a requester with requester permissions, then the fields that be parsed are limited. A requester can parse only those fields that he can view in the request form while creating a request. 
   • If the e-mail sender is a technician with technician permissions, then the fields that can be parsed are same as those fields that he can view in the request form while creating a request. 
   • Fields that can be parsed are LEVEL, MODE, PRIORITY, URGENCY, IMPACT, IMPACTDETAILS, CATEGORY, SUBCATEGORY, ITEM, GROUP, TECHNICIAN, TECHNICIANEMAIL, REQUESTER, REQUESTEREMAIL, REQUESTID, REQUESTTEMPLATE, REQUESTTYPE, STATUS, SITE, ASSET, RESOLUTION and additional field label (the field label given in the e-mail must match the field label set in the product) 
   • To change the fields that a requester or a technician can parse, go to Admin --> Request Templates (under Helpdesk domain), select Default Template and add or remove the fields. 

• The RequestId present in the description of the e-mail it will be given higher precedence over the RequestId present in the subject of the e-mail.