Incoming mail - picking up request ID from message subject

[Martyn Houghton]

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?

[Guest]

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

[Martyn Houghton]

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

[Martyn Houghton]

Bob

Just wondering if there is a RFC/Chang reference yet for this requirement, as it is quite critical for us?

Cheers

Martyn

[James Ainsworth]

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

[James Ainsworth]

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.

[Martyn Houghton]

James

Thanks for the update. That will be a great relief.

Cheers

Martyn

[James Ainsworth]

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?

[Martyn Houghton]

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

[Guest Chaz]

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.

[Martyn Houghton]

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

[Martyn Houghton]

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

[James Ainsworth]

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

[Martyn Houghton]

@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

[James Ainsworth]

Hi Martyn, 

It is at the top of the development queue so we should see it worked on shortly.

Regards,

James

[James Ainsworth]

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

[Martyn Houghton]

@James Ainsworth

Thanks for the update. Do you know what build/version they will be released in and rough timesclae?

Cheers

Martyn

[James Ainsworth]

Hi Martyn,

This will be available in the next update of Service Manager 2.38 which is being prepared for release.  

James

[Martyn Houghton]

@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

[Guest Chaz]

@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.

[Martyn Houghton]

@cchana

I will retest and let you know.

Cheers

Martyn

[James Ainsworth]

Hi Martyn,

I just wanted to see how your testing was going.  Have you had any success?

Regards,

James

[Martyn Houghton]

@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

[James Ainsworth]

Thanks Martyn.  I will inform the dev team to also have a look to see if they can spot something.

Regards,

James

[James Ainsworth]

@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