Raising a request from email results in orphaned ticket

[Gareth Cantrell]

We are automatically raising tickets from emails against a specific Service/Catalog item and this seems to work well when the system raises the ticket.

However, we also have exceptions where tickets need to be manually raised from the "+ Raise Request" option and when we do this, against the exact same Service/Catalog item combination, an error is raised and the ticket shows in the "No Team Assigned" list and with no associated business process.

As you can see from the below image, this was attempted 7 times resulting in 7 orphaned tickets:

 

How do I go about understanding why this is happening, and more importantly, how to STOP this from happening?

 

Thanks,

Gareth

[James Ainsworth]

Hi Gareth,

Thanks for your post.

As you have a Premier Success Plan, for something like this it might be worth raising a support request.  I don't have access to your data or the details of the issue so I'm unable to pinpoint what the issue might be.

Here are some considerations that you can look into...  

The automatic raising of a request from an email using Email Routing does not use Intelligent Capture.  As it is automated there isn't a person involved that would answer the questions, so it uses Email Request Templates to set some defaults on the new request.  When it comes to manually raising a request from an email, it will use an Intelligent Capture script.  There is a setting that lets you specify which Intelligent Capture script is used when manually raising a request from an email. 

 

If nothing is specified in this setting, I believe it will then fall back onto this setting and used what is specified here.

 

 

My thoughts are that there is an issue with the Intelligent Capture script that is being used when manually raising a request from an email.  It might be that the email doesn't have all the information needed to run through all the questions in the selected capture script.  This is the reason for the setting app.itsm.progressiveCapture.newRequestFromEmail so that you can create a unique intelligent capture script to manage how requests raised from emails are managed.

 

I hope that helps.  Let us know if you have any questions.

 

 

[Gareth Cantrell]

@James Ainsworth thanks for your response.

We don't have anything specified in that setting.

What happens is when we click "+ Raise Request", we go through the default IC as mentioned, which asks us for the service and catalog item.

Even after selecting this correctly (i.e. using exactly the same service & catalog item that is configured in our routing rule template), it is not attaching to the workflow specified in that catalog item.

[James Ainsworth]

Hi Gareth,

I can only suspect that there is something in your default IC that is not being populated correctly when manually raising from an email compared to manually raising from the request list.  Without being able to see your Intelligent Capture I wouldn't be able to tell.   

The error message Failed to log request does suggest that the record has not been added correctly which is likely due to missing information during the Intelligent Capture phase that is required for a request to be logged.  One thing that can cause problems is when there are duplicate email addresses set against user accounts.  For example, during the raising of the request, it looks up the email address to confirm which customer the email is from, but it finds two results and doesn't know which customer to assign the request to.  This could then have a knock-on effect where it fails to associate with the service and a request catalog item because, with no customer, it can't check for subscriptions to the service.

As suggested above, you may want to raise a support request with Hornbill.

[Berto2002]

I think I am seeing a similar thing: BPMs are not being picked-up when we have inbound emails pointing to the inbound templates. I am investigating.

@James Ainsworth may be worth a gander in case something is going wrong.

[James Ainsworth]

6 hours ago, Berto2002 said:

BPMs are not being picked-up when we have inbound emails pointing to the inbound templates.

Hi @Berto2002

Are these inbound emails being manually raised as requests, as that's what is being discussed here?  Inbound templates are only used when an email automatically creates a request using the Routing Rules.  

[Steve Giller]

@James Ainsworth I believe this is the issue we resolved for @Berto2002 on a Support Request - there was a problem with the Workflow that was preventing it from spawning.

@Gareth Cantrell if James's suggestions don't resolve the issue raise a Support Request and we'll take a look.

[Gareth Cantrell]

I think I found the issue.

The setting app.itsm.progressiveCapture.newRequestFromEmail had no value, so the default IC "new request" was being used (and by default, I mean the setting: app.itsm.progressiveCapture.newRequest = "new request")

This then did a switch capture to the "new service request" IC which in turn performed a switch capture to the IC configured to the catalog item.

The IC for "new request" is "Co-worker search" -> "Request type details" -> "Select service" -> "branch on request type" -> switch capture (to "new service request" in this case)

The IC for "new service request" is: "Co-worker search" -> "Select service" -> switch capture (to "IT - Service Request")

The IC for "IT - Service Request" is: "Request details" -> "Attachments"

I set the app.itsm.progressiveCapture.newRequestFromEmail setting to "new service request", bypassing the generic "new request" IC and now all is working as expected.

[Steve Giller]

Thanks for the update, glad that's working for you now.