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.