Can we reassign tickets to other teams?

Non-ISS teams will be able to assign tickets within their own team and to ISS teams that they currently collaborate with, for example QUILT can reassign to Service Desk and Learning Technologies. Note that: After the Non-ISS team has reassigned the ticket, an on-screen error message will appear due to the fact that they are no longer permitted to view/process the ticket.

ISS teams can still reassign tickets between teams however we would encourage staff to reassign any tickets that have been incorrectly assigned back to the Service Desk with an explanation of why it’s not right, and a suggestion of where it should go.  This will help the Service Desk improve initial ticket logging and redirection.

Key Contacts

We have a Stakeholders Group who have given a lot of input into project.  Most of these people have been involved in the project from the beginning, working with the project team to review requirements and evaluate potential systems/suppliers, scoring the various offerings and assisting with selection of the final solution.

This group has kindly agreed to act as key contacts for the project – if you have any questions you can of course contact the project team but if it’s easier for you, please contact your nearest Stakeholder Group member, who are:

  • Ian Pitcher – EEE, SAgE
  • Wendy Craig – ICM, FMS
  • Rebecca McCready – Learning support, FMS
  • Anne Middleton – Robinson Library
  • Keith Lockhart – ECLS, HASS
  • David Lowe, Language Centre, HASS
  • Janet Watson, Business Systems, ISS
  • Stuart Frost, Infrastructure and Architecture, ISS
  • Tricia Blakey, Service Desk, ISS
  • Dave Alsop, Digital Media Services, ISS

Project contributors

The people involved in the system configuration and testing include:

Core project team – Sharon Mossman (Project Manager), Dave Churchley, Lisa Dimmick, and Dawn Darby

Configuration and general advice – Steven Cuthill, Gavin Younger, Sean Gray, Michael Carrick, Jo Robinson-Lamb, Richard James, Cal Racey, Chris Franks, Pete Harvey, Peter Smith, Paul Thompson, Ian McAlpine, Ben Allen, Paul Haldane, John Donaldson, Chris Schroeder, Richard Kirkpatrick and Linda cunningham

UAT – Vikki Williams, Stephen Goodey, Ian Grunhut, Susan Tarlarini, Paul Pattison, Tricia Blakey, Deborah Harris, Neil Parkin, Paul Roberts, Stuart Frost, John Donaldson, Anne Murphy, Andy Chau, Peter Chau

Training – Roy Clark and Andy Proctor

Thanks! We couldn’t have made it this far without you!

(if I’ve forgotten anyone, I’m really sorry!)

This week, we will be mostly doing…

UAT

UAT is progressing, with most of Incident Management tested and starting on the Service Request process on Monday 29th April.  As issues are discovered and re-created by Dawn and the testing team, they are prioritised and added to a list for Lisa and Dave to work on resolving.

Email configuration

This is a time-consuming piece of work with a number of aspects to consider, including working out which steps in the processes should trigger notifications, who gets them, defining the content, configuring them in the system, then testing that it’s working – and that’s only one type of notification!  This one looks like it’s going to be with us for some time….

Dashboards

Probably the least urgent for day 1, but a really ‘nice-to-have’.  The facility to see at a glance ‘what’s hot and what’s not’ is something the old system was lacking.

Training and awareness presentations

Roy and Andy are working on the slides for the user presentations that they will be delivering from next week.  At least one of the sessions will be ReCapped.

Email

Our configuration fortnight is rapidly coming to an end but this evening, for various reasons, I’m just thinking about email.

Lisa, as planned, was busily entering the content for the system-generated notification emails when a nagging thought pushed its way to the front of my mind to throw a little spanner into the works.

After a quick chat with Paul T, who confirmed my fears (and didn’t know of any good way around them), I soon realised that we should no longer continue to forge ahead with Plan A: using mailto links to allow users (or customers, if you prefer) to automatically update their tickets via email in response to a system-generated message. I won’t go into details here of why this was plan A but suffice to say that we wanted to direct the inbound emails to specific email addresses for specific purposes. I still think it would have been a sound plan in a controlled, corporate environment; it is just not compatible with the uncontrolled nature of the University (and that’s before you even begin to consider students!).

A deeper discussion followed with Ben who had just happened to overhear some of my conversation with Paul and decided to butt in. Ben’s knowledge of email in general and the University’s email systems in particular were very helpful in steering me through all of the possibilities, weighing up the advantages and disadvantages of each, and providing an expert opinion to back up and give me confidence in the same Plan B that I had already come up with! So we are now planning to accept replies to the outbound email address and use server-side Exchange Inbox rules to redirect the messages to the specific inbound email addresses, as required. A quick look in OWA (a good tip from Ben to ensure that we’re not setting client-side rules) confirmed that this approach should work as long as we are careful with the wording of the outbound emails. I also have a partly-formulated Plan C, just in case, involving a web form accepting parameters from a link in the notification email.

Now that we had some email features to test, we asked Steve to switch on the mail services on the dev application server. He was sensibly cautious of doing this, not wanting to spam people with irrelevant emails relating to test tickets in the system about which they had knowledge. Before our consultant had left he had run a script on the database for just this kind of occasion. The script set all users in the system to not receive email. Just to make sure, I knocked up a couple of quick queries which allowed me to confirm that this setting had been applied to all but the newest members of the University, who must have been imported into the system since the script was run. Michael, our friendly DBA, re-ran the script and I could then see that no user was set to receive emails. I changed this setting just for my own account so that I would be able to see the emails.

I confirmed to Steve that I was definitely happy for him to switch on the mail services and then followed a few hectic moments. Thanks to Ursula, Gary and Adele for being on the ball and letting us know straight away that the dev system was sending out emails that it shouldn’t be.

Mild panic ensued but Paul H’s quick work helped to smoothly restore order; he provided Sharon with a list of all the 80 or so email addresses that had received a message from the dev system – luckily they were all members of ISS. Meanwhile, Sharon quickly informed the Service Desk and, after receiving Paul’s list, composed an email to all ISS staff to explain what had happened whilst Paul managed to find and remove some more messages from the mail gateway before they were delivered to the recipients. It appears that the system was trying to email all ISS staff but no-one from outside of ISS. I currently have two (or three) theories about what happened.

The main positive outcome of this was the subsequent discussion with Paul; he offered to provide us with a ‘safe’ environment for testing the emails from the system so that we can see them but they will never be delivered to the recipients’ mailboxes. This is how they test the SAP CRM emails.

The other positive I’ve taken from this is that it’s reassuring and satisfying for me to know that I work with so many experts and competent professionals.

System training

Q – Will I receive training on how to use the new system?

A – Yes, Roy Clark and Andy Proctor will deliver the training; we will contact users via email to publicise the training dates and times available.

Historic data from old system

Q – Will tickets and other data be transferred into the new system?

A – No, we won’t be migrating any historic data.  There are two options for change over: either re-enter any open tickets in to the new system (advised), or log a place-holder within the new system that refers to the ticket within the old system.  Please bear in mind that the old system will become unavailable at some point in the future (date still TBC),

Visibility of tickets owned by other teams

Q – Is there a way to retain visibility of incidents that need to be passed on to another team?

A – Yes, for ISS there is a ‘watch list’ facility which allows the analyst to monitor tickets regardless of which team they are assigned to.  There are some restrictions on this, e.g. analysts will not be allowed to see some information security incidents.

Task assignment to multiple teams

Q – Will we have the ability to assign an incident to multiple teams (e.g. when it isn’t totally clear exactly where to route an incident or an incident may need input from more than one team and both could be investigating simultaneously)?

A – Yes, for ISS the incident management process will allow ‘tasks’ to be created against the incident ticket, where the original ticket is retained by the incident owner (or team) but the tasks can be assigned to other teams.