This is a public Idea Center  publicRSS

Idea

    24 liked this

    [Delivered] Custom Mail Templates for Service
    Idea posted June 18, 2009 by MikePInnovator, last edited October 6, 2014 by KeriInnovator, tagged Incident Management, System Admin and Configuration 
    22326 Views, 13 Comments
    Title:
    [Delivered] Custom Mail Templates for Service
    User Story / Description:

    We have a variety of admin and end user personae that may get notified when an incident is created or updated.  It is important that we be able to vary the email content sent based on these personas.   One option would be to allow a business rule to choose a report who's content would be sent as the email.  Reports can be configured to look like incidents or spreadsheets. 

    Scenario: 

    Jon (user at MegaCorp with a Platinum SLA) updates a priority one incident for a new software product.   The user receives an auto response email based on their SLA.

    Different messages go out to different personas:

    Lou (the 'on-call' CSR) gets two email notifications.

      Full detail with a screenpop URL for quick loading of the incident

      Tiny (iPhone friendly) email notification with the latest thread(s) at the very top of the message.  It contains a URL to the admin WAP interface.

    Jill and Bob (coworkers of Jon at MegaCorp) who are on the contacts list for this incident receive an email similar to the current email response but starts with "You are receiving this email because you are listed on incident that was updated by your colleague. If you don't want to receive any more updates on this incident click here to unsubscribe from this incident."  (This scenario assumes functionality that does not exist today.)

    Kevin (account manager handling the MegaCorp account) receives an email similar to the Admin Notification email including Notes.  It starts "You are receiving this email because one of your Platinum customers has updated a Priority 1 incident."  This email would include a list of contacts on this incident along with their phone numbers.  It would also contain a list of all Open incidents,  and all P1 incident in the last month for this client.

    Elizabeth and Steve (Engineering Project Managers) would receive an email similar to the Admin Notification email including Notes.  It starts "You are receiving this email because a customer has updated an incident on one of your new software releases.

    ...and so on.  The list of possible variations is endless.

    I would settle for template files as long as they were easy to edit and you could select the template you wanted for each business rule.

    I encourage others to add their own scenarios here.

    Comment

     

    • DaveF
      I would like to echo Mike's encouragement - please keep those usage scenario's coming.
    • SabrixDaniel

      I have an enhancement request for this. My idea was that we have a combination of the WYSIWYG editor we use now for mailings and surveys, with access to merge fields and all, and the response templates. So we build the notification email in the editor, using merge fields and the normal stuff, then when we "send email notification" we would be able to choose an email template that has been built.

       

      This is on my top 3 list of enhancements that would make my life WAY better. 

    • Danny

      I have had a number of requests for formatted alerts to pagers, phones, and other devices. The other ticketing systems on campus support templating of messages, but RNT doesn't.

       

      I did try to use forwarding in a business rule to an alpha-numeric pager, but there is so much overhead information in the message, that the 256 characters were used up with irrelevant (to the engineer) details.

       

      Priority 1 issues are particularly significant. Engineers can't get back to an office, or often even to a computer, in order to get initial trouble details, or updates from other working on the ticket. A templating system that would allow just the fields we needed to be sent in a page would be ideal.

    • Cheyney

      This issue is probably the most useful feature I could use.

       

      I have a workaround but it is a little ugly unless you modify some of the text inserted by the PHP files (just remove the headings)

       

      So...

       

      1) Create a RULE Standard Text

      2) Insert the Custom Fields needed into the RULE Standard Text

      3) Create a Function that is called when needed to send the custom email.

      4) Create a rule in the Function for each email type to send that references the specific RULE Standard text

      5) Send the email

       

      Kind of hard to explain without pictures but it works for us.

       

      If anyone needs the specifics send me a message.

       

      Cheyney.

    • ZephreumH
      I am not sure how this pretains to the original post that lead me to be sent here, but I am still wondering about the future ability to limit Incident Custom fields that are being included in forwwarded emails out of RN. Here is the original thread that brought me to here eventually. POst
    • compassionAU

      Is this ever going to be implemented anytime soon? This discussion has been dragging on over 2 customer forum threads for over a year and now in the IdeaLab. We are still awaiting for RN production team's action plan on this.

       

      All we need a simple solution for a starter - ability to remove all the incident fields displayed when "forward" an email from RN. Every time we use forward button, every incident field appears in one long email, and the recipient almost always complains. Once the option to forward message only feature is enabled, the rest can be implemented in a modular fashion.   

       

      Please provide a timeline for this simple roadmap. Then progressively implement the rest in the future releases.

    • Greg L

      Have to add my 2 cents worth here.

      I find it hard to believe how inflexible RightNow is in terms of formatting emails.

      Something as simple as changing the colour or size of headings in outgoing emails requires modification of the underlying PHP files. Modifying those inevitably causes issues in future upgrades and usually comes at a cost from Professional Services.

      Considering all the great customisation available for end-user pages in Customer Portal these days - I'd have hoped to see something similar for email. It's such an integral part of the product.

      I totally agree with Compassion AU that there should at least be some way to exclude custom fields when forwarding an incident as that is a common sense option.

    • Ryan Young

      Have there been any developments on this topic?  I agree with Mr. Jang, and a very simple "no-custom-fields" option would be extremely helpful when using the built-in "forward" functionality on the incident workspace.  All of the additional functionality would be great, but starting with this simple change would make an entire world of difference for our company.  Thank you in advance for any updates regarding this topic.

      Ryan Young

    • Susie

      Thanks everyone for the posts.  The more votes this gets, the more it rises in priority.  Keep on voting and letting us know the use case that you are trying to solve.  This is definitely on the roadmap - probably not 2011 but stay tuned...

      Thanks again!

      -Susie

    • Pat (EEOC)

      I will add my request for this as well...

      From another thread I posted:

      "How do I limit the fields that are included within a forwarded incident?  I recently created a new workspace for quality control purposes and each of the new custom fields that I created for the new workspace are now showing up on all forwarded incidents as well as notifications.  We are not even using the new workspace yet but there must be a setting in the Common > Site Configuration > File Manager > Mail directory that is allowing any and all custom fields to be displayed on Forwarded incidents.  I reviewed the details.phph file and searched for some of the new custom field names but found nothing. 

      Any ideas what or where the code is that is forcing all custom fields to display."

       

      So, having a way to limit the display of custom fields on forwards and emails is a "must-have" and should be within our basic admin settings access.

       

      Thanks,

      Pat

    • Susie

      Just an update... This project is under way... The more votes and use cases we hear- the more it raises in priority so keep on voting for this and sharing how you plan to use.

      Thanks everyone for the votes and comments so far and let's keep them coming!

      -Susie

    • DanO

      Really hard to believe this hasn't happened yet... seems like this would be part of the basic functionality really.  Add my vote for getting it implemented ASAP.

      Someone in a previous post had mentioned needing to modify the mail files to hack out this sort of thing on our own, does anyone know which file(s) specifically?  We have a HUGE need to be able to choose which fields to send or not send when using "Email Incident Information" in business rules depending on the rule and its audience. 

       

      As a second attempt, I've created a custom report that does this sort of custom field filtering and formatting perfectly, but I haven't been able to find a configuration setting to tell the system to use my custom report for "Email Incident Information" in business rules instead of the system default.

      I'm sure there's an AC_ID listed for the default system report - probably buried in the settings or message bases somewhere... does anyone know where to find it by chance?  Honestly that would be the fastest solution to this issue - just let us tell the system *which* report to use when forwarding or emailing incident information to someone... then we can customize it as needed, and life is good.

       

      Thanks!!

      DanO

    • Keri

      Hello all,

      Message Templates should fit your needs for the vast majority of these scenarios. Let me explain the first several scenarios listed:

      Jon (user at MegaCorp with a Platinum SLA) updates a priority one incident for a new software product.   The user receives an auto response email based on their SLA.

      This one is a basic Conditional/Case Section scenario, with the conditional content displayed based on the SLA of the incident. It may belong in Question Receipt, or within Incident Unresolved/Solved/Waiting emails - this depends on the timing of the update and what the status is on the reply. If you want the system to auto-reply to an updated incident, you could choose to create a rule that looks for the update/SLA combo and adds a Standard Text response and sends that response to the sender. The latter is more rules and not Message Templates, but it could be done.

      Different messages go out to different personas:

      Lou (the 'on-call' CSR) gets two email notifications.

        Full detail with a screenpop URL for quick loading of the incident

        Tiny (iPhone friendly) email notification with the latest thread(s) at the very top of the message.  It contains a URL to the admin WAP interface.

      Message Templates have been designed with an optimized look and feel, intended for easier readability on small devices. The great part is that these emails also look great on a desktop. Links cannot be based on the type of device, but you can link to the product, to a Survey, or use a Merge Report and the URL Options within to create an actionable hyperlink in the email message.

      Jill and Bob (coworkers of Jon at MegaCorp) who are on the contacts list for this incident receive an email similar to the current email response but starts with "You are receiving this email because you are listed on incident that was updated by your colleague. If you don't want to receive any more updates on this incident click here to unsubscribe from this incident."  (This scenario assumes functionality that does not exist today.)

      This one is still functionality that doesn't exist. If you'd like to post it as a new idea, feel free.

      Kevin (account manager handling the MegaCorp account) receives an email similar to the Admin Notification email including Notes.  It starts "You are receiving this email because one of your Platinum customers has updated a Priority 1 incident."  This email would include a list of contacts on this incident along with their phone numbers.  It would also contain a list of all Open incidents,  and all P1 incident in the last month for this client.

      This one could be handled with an Email Incident Information Message Template + Rule combo. You could use a Conditional Section to show/hide the data you wanted only the account manager to see - possibly based on Account Profile or other information. Put your merge reports for Contacts for the Org and for the Incidents into this conditional section as well.

      Elizabeth and Steve (Engineering Project Managers) would receive an email similar to the Admin Notification email including Notes.  It starts "You are receiving this email because a customer has updated an incident on one of your new software releases.

      This could be another Email Incident Information-type message with different details. Determining your big hitter options first would be key for implementation. Perhaps there are other things we could improve in Message Templates to help you in the future, but this list seems manageable.

      Read more about Message Templates in the documentation and consider migrating to Message Templates soon (if you haven't already). Post any new ideas here in the Idea Lab, or questions to the Discussion Forum. We are here to help!

      Keri