Martyn Houghton Posted December 14, 2015 Share Posted December 14, 2015 Just testing incoming mail elements of Service Manager and it appears to try match the customer incoming email address against the organisations/users, but does not seem to be picking up the request reference in the message subject, allowing the option to update the related incident. I am wondering if I am missing a setting/configuration to enable this? Link to comment Share on other sites More sharing options...
Guest Posted December 15, 2015 Share Posted December 15, 2015 Hi Martyn, Currently, when applying an incoming email update to an existing request, the search is only performed on the email address of the sender to see which tickets they have logged. Many of our customers have custom references for their tickets, so there is not currently a dynamic way to search the subject line for a reference that is consistent for everyone. I'll raise this with our development team though, to see what we can do to improve this functionality and keep you updated with the results. Kind Regards, Bob Link to comment Share on other sites More sharing options...
Martyn Houghton Posted December 16, 2015 Author Share Posted December 16, 2015 Bob Thanks for the reply. Least I know it not me missing something. As we often have a number of potential external contacts from an organisation involved in a request, so the common key for us is request reference rather than the customer contact. This functionality is something we rely on very heavily in SupportWorks, so is quite critical for us. Therefore an I request a formal RFC be raised regarding the implementation of the same request identification from the subject line as available in ITSM-F 7.6.2 with customer configurable request prefixes. Thanks Martyn Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 6, 2016 Author Share Posted January 6, 2016 Bob Just wondering if there is a RFC/Chang reference yet for this requirement, as it is quite critical for us? Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 7, 2016 Share Posted January 7, 2016 Hi Martyn, Thanks for your post. We are currently investigating this as a defect (PM00136990). It is already on our development queue and we will be sure to update you on the progress. Kind regards, James Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 19, 2016 Share Posted January 19, 2016 We are looking to provide a solution for this in the next update to Service Manager (2.1.9). This should be available next week. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 19, 2016 Author Share Posted January 19, 2016 James Thanks for the update. That will be a great relief. Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted May 9, 2016 Share Posted May 9, 2016 Hi Martyn, There was a fix provided the Service Manager update 2.1.9 and I just wanted to check if this was now working for you? Link to comment Share on other sites More sharing options...
Martyn Houghton Posted May 18, 2016 Author Share Posted May 18, 2016 James Sorry for the delay in getting back to you. This is fixed if you do not have custom request prefixes. We have just started testing using our custom prefix and the 'Apply to Request' function presumes the standard default of prefix of IN, not our customised prefix, so it is not able to locate the request. If you manually amend the reference it has extracted from the email, you can then get it to match, but as part of the automatic matching it should apply(re-apply) the default prefix after extracting the reference number. I have not checked it yet with custom prefix for the other call classes yet. Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Chaz Posted May 19, 2016 Share Posted May 19, 2016 Hi Martyn, Something came up before but in that scenario there were other ways around this restriction. I've raised a development task (KE00141270) which will provide an app setting in which you can define your own pattern (it will include the default) for matching. I can't give any specifics on time, but we will look into it. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted May 19, 2016 Author Share Posted May 19, 2016 Thanks for the update. At the moment we can work around it, but it would be good to be able to automate this with the new matching setting. Cheers Martyn Link to comment Share on other sites More sharing options...
Martyn Houghton Posted August 2, 2016 Author Share Posted August 2, 2016 Can I have an updated on the issue of the Update Request from email not working with custom prefixes (KE00141270) as this is been a long outstanding issue. Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted August 2, 2016 Share Posted August 2, 2016 Hi Martyn, Sorry for the delay on this one. It is still a priority for us and is in the queue for development. I will let you know once we are closer to starting this work. James Link to comment Share on other sites More sharing options...
Martyn Houghton Posted November 8, 2016 Author Share Posted November 8, 2016 @James Ainsworth Is there an update on KE00141270 as this is still causing us an additional step for every email we deal with. Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted November 8, 2016 Share Posted November 8, 2016 Hi Martyn, It is at the top of the development queue so we should see it worked on shortly. Regards, James Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 5, 2017 Share Posted January 5, 2017 Hi Martyn, The Known Error discussed above has been completed. There are 5 new Service Manager Settings which will soon be available that lets you define the regex expressions to help match the Request ID lookup when you are manually applying an email to a request. com.hornbill.servicemanager.regex.changeRequest.id com.hornbill.servicemanager.regex.incident.id com.hornbill.servicemanager.regex.knownError.id com.hornbill.servicemanager.regex.problem.id com.hornbill.servicemanager.regex.serviceRequest.id These settings are accessed in Administration under Service Manager > Settings. Let us know if you need any help with setting these up. Regards, James Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 5, 2017 Author Share Posted January 5, 2017 @James Ainsworth Thanks for the update. Do you know what build/version they will be released in and rough timesclae? Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 5, 2017 Share Posted January 5, 2017 Hi Martyn, This will be available in the next update of Service Manager 2.38 which is being prepared for release. James Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 12, 2017 Author Share Posted January 12, 2017 @James Ainsworth We have applied 2.38.0 and I have updated the settings to take into account our prefix but it is still not matching and selecting the case. Cheers Martyn Link to comment Share on other sites More sharing options...
Guest Chaz Posted January 16, 2017 Share Posted January 16, 2017 @Martyn Houghton we've been looking into this and have now used the exact configuration you have and can see it working for us in 2.38.0 Just wondering if this was an issue where the app was updated but the user(s) had not refreshed the page which means the code would not necessarily be available to them. If you could confirm if this is still not working for you and your team, that would be great. Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 16, 2017 Author Share Posted January 16, 2017 @cchana I will retest and let you know. Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 25, 2017 Share Posted January 25, 2017 Hi Martyn, I just wanted to see how your testing was going. Have you had any success? Regards, James Link to comment Share on other sites More sharing options...
Martyn Houghton Posted January 30, 2017 Author Share Posted January 30, 2017 @James Ainsworth It is working most of the time (which our 1st Tier are very grateful about), however where issues start to occur is when the source email address does not match that of customer's email on the request which is identified by the full request reference number in the subject line. It seems the customer matching element is unsettling/taking precedence over the request reference. As mentioned above, we often have a number of external contacts responding via email reference a request, who are not the assigned customer contact on the call, i.e. they are interested parties that we may have emailed them as 'connections' on the request. I will get some worked examples collated to demonstrate the issue in more detail. Cheers Martyn Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 30, 2017 Share Posted January 30, 2017 Thanks Martyn. I will inform the dev team to also have a look to see if they can spot something. Regards, James Link to comment Share on other sites More sharing options...
James Ainsworth Posted January 30, 2017 Share Posted January 30, 2017 @Martyn Houghton I was wondering if you have the setting app.email.routing.rules.unknownUsers.allow enabled? I believe that this allows updates from an email that has a different email address from the customer that is listed on the request. Regards, James Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now