| Author |
Message |
|
|
What we did was edit the alternate email client so that the "reply to" address was our helpdesk integration email address. The SR # in the subject line would direct it to the SR.
As for who sent the email (which admin), we are relying on the assigned admin as being the identifying factor. Either that or inserting a comment/signature in the email identifying the specific admin.
|
|
|
In our environment, we use it this way:
Priority - our sites are categorized by sales volume (revenue)
Urgency - the type of issue is categorized
So ...
A priority A store with a medium urgency issue is roughly equivalent to a priority C store with a high urgency issue. Greatly over-simplified but generally tied to potential lost revenue (with exceptions as usual).
|
|
|
|
You can use the escalation rules to do that based on time passed.
|
|
|
No problem - I had to ask the same question when I started using email integration. 
|
|
|
Patrick,
If the reply email contains the SR # in the subject line of the email (including the #, such as #12345 or #12,345) then the email will attach itself to the corresponding SR. We use this extensively in our implementation of SysAid.
|
|
|
|
Speaking for myself, as long as the pay/benefits are within reason, the primary "driver" is how I can apply what I know, or know I can learn, to do things better or to do things that were thought not to be achievable.
|
|
|
Haim,
I think I found the correct expression for blank lines - "^$" (without the quotes of course  ). I am by no means a regex guru - just persistent at Googling.
I can still create SRs with non-blank subject lines, except for the other expressions I am blocking. My expression entry is "^$|\b[1-9][0-9]{2}\b|#\b[1-9][0-9]{2}\b", which blocks blank subject lines, lines containing only numbers 001 thru 999, and the same number range with a "#" in front (it's a long story but a source of contention for me). All of my SRs are at least 4 digits so this doesn't affect them.
Actually, I went back and "learned" a little more about regex (translation: Google) and modified my regular expression entry to the following (each "|" separated expression on a new line to read easier here):
^$ ->blank line
^[Ss]tore # [0-9]{3} ->
^[Ss]tore #[0-9]{3} ->-> Store (or store) # 000-999; variations of # space nnn, #nnn, or just nnn
^[Ss]tore [0-9]{3} ->
^[Ss]tore # [0-9]{2} ->
^[Ss]tore #[0-9]{2} ->-> Store (or store) #00-99; variations of # space nn, #nn, or just nn
^[Ss]tore [0-9]{2} ->
^# [0-9]{3}$ ->
^#[0-9]{3}$ ->
^[0-9]{3}$ ->-> Same as above for numbers only
^# [0-9]{2}$ ->
^#[0-9]{2}$ ->
^[0-9]{2}$ ->
We have over 200 stores that send emails in and some are new to computers, email structure, etc. (amazing, but true); others just don't want to follow the rules. I implemented these filters to stop emails from generating SR's that required unnecessary edits on our part to process (for example, you can create a SR with no title via email integration but when an admin edits the SR he/she HAS to put in a title or they cannot save the changes). The store number thing is pretty much me being anal about looking on my Blackberry and seeing SR numbers and just a store number for the description of the request.
|
|
|
http://www.google.com
http://www.tek-tips.com
and of course,
www.ilient.com 
|
|
|
|
Mostly Google Chrome, except where KB is involved. End-users IE6 or IE7.
|
|
|
|
I agree. I have been using Chrome as well, almost exclusively for SysAid and have been pleased with the results. Same issues here concerning KB.
|
|
|
Ah, "ask and yea shall receive"! Thank you Haim - that was the "missing link". 
|
|
|
Can anyone enlighten me on the issue of Child Assets. I have been unable to see how to implement this (I assume this would be used for associating down-level components of an asset that can be associated with one asset or another - such as a monitor to a PC). The Asset Information tab shows it but I find no other reference. 
|
|
|
I'm not so sure that it is working properly. If time permits I will test again today. I have had SRs that were set up in a parent/child relationship but when I closed the parent, the child SRs did not close. I could not close them without removing the link to the parent and closing each one individually.
What would really be benificial is to be able to select one or more SRs and, similar to selecting multiple SRs and changing their status, be able to assign them to a specified parent SR either by specifying or by search. This would help when events occur and multiple SRs get opened via email integration before we identify a pattern where it becomes necessary to generate a parent SR to watch the children
|
|
|
|
No, nothing yet.
|
|
|
|
How about ignoring emails with blank subject lines (which translate into no Title in the SR)?
|
|
|
