Jump to content

Issue with raising incidents


derekgreen

Recommended Posts

Hi. Have had issues from a few of our users when they raise incidents. They are reporting an error when they complete and submit the form, however the call is appearing on Service Desk. Problem here is that the calls are not being auto assigned to Service Desk, no emails are being sent out to the user and Service Desk admins and we are unable to assign the calls or prioritise them as per our business process.

Upgraded to 2.37 yesterday.

Link to comment
Share on other sites

Hi Derek,

This is something that has been reported and we are currently investigating it. I will advise you as soon as we have something.

Thanks

Pamela

Link to comment
Share on other sites

Our customers are also experiencing problems with adding attachments to tickets logged via the portal.  Tickets are being logged but not following the associated Business Process and just sitting in a black hole of no team assigned without the relevant attachment

Link to comment
Share on other sites

Hi all

We released Service Manager 2.38 which should have a higher level of logging to help us diagnose this issue. Could you update your systems so that next time it happens and we analyse the logs, we get more helpful information.

Thanks

Pamela

Link to comment
Share on other sites

There is an issue around request logged via portal when adding attachments to the request. The log request process fails during file attachments phase and "breaks" the log request process. This is why the request is still being created but the BP is not spawned on these requests. This is currently being investigated.

Link to comment
Share on other sites

@Victor Were there any changes made to the core platform yesterday? Seems strange that this just started happening for everyone yesterday without any updates (by us users) to the system.

Regards

 

Keith

Link to comment
Share on other sites

@Keith @Victor- we have decided to delay updates (staying on 2.36.8 I think) to see if anyone reports issues after applying a patches ( a previous one severely impacted us). Now I see even that doesn't prevent problems - I can't believe a change hasn't been applied to the system or else why wouldn't we have seen this issue earlier. Its the whole reason we have operate change management - a working system shouldn't break.

For the record we see the issue when customers try and submit a ticket with an attachment, although it seems more severe now I dealt with someone last night who reported the issue but when I retested with them the file attached ok. So maybe its an intermittent issue although it is becoming much more serious.

Link to comment
Share on other sites

@nasimg This issue was first reported last year and was being investigated all along. It did not come up as a result of any updates we did. You are right in saying it is intermittent which is why it has not been easy to investigate. The update in 2.38 is meant to provide a higher level of logging to help identify the issue, not fix it. This issue has been reported when customers are submitting requests with attachments. As I said before, now that the higher level of logging is available, as at this morning in 2.38, our team is investigating to find the root cause.

 

Thanks

Pamela

 

Link to comment
Share on other sites

@all

I think we have some good news. In our latest platform release we addressed an issue whereby the file pathing was incorrect and was affecting some API calls. From our investigations it seems that it also affected file attachments on portal so the issue might have been fixed in passing.

I have tried this in ESP build 2675 (which is the current platform build) and I replicated the issue reported. However my test instance was upgraded to latest ESP build 2678 (that contains the file pathing fix) and the issue seems to be resolved. Current plan was to deploy this build tonight.

Therefore we have pushed the latest platform ESP build (2678) to live instances. By default the deployment for this will happen after 01:00 the next day, but this can be changed if you like. We have a system setting autoUpdate.maintenanceWindow (Home -> System -> Settings -> Advanced) which dictates when the platform updates are deployed. You can change it to have this deployed sooner. The build controller checks this every hour and will deploy if within the set timeframe. Please note that if you choose to change this and deploy it during business hours you will have an approx. 5 min downtime and analysts will not be able to log in or might be requested to re-establish the session (disconnect/reconnect).

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...