Jump to content

SLA Escalation Events

Drew Davies

Recommended Posts


I've been testing the SLA escalation events with the email notifications and have a couple of issues:


1) Both the 'Summary' variable and the 'Subject' variable is all lower case when sent in the email

2) The 'Status' variable in the email template includes the full status name exactly as in the database. This means it says 'status.open' rather than 'Open'

3) Customer name variable comes across as blank


Are these things that can be fixed?


Link to comment
Share on other sites

I believe that if you use variables, the case of the placeholder affects the final value - so {{.H_summary}} will produce "Summary of the call where {{.h_summary}} will produce "summary of the call" and {{.H_SUMMARY}} will produce "SUMMARY OF THE CALL"

Link to comment
Share on other sites

6 minutes ago, Drew Davies said:

don't suppose you know the answer to the 'Status' part though do you?

I have answers for everything! .. :P (joking)

On this occasion, I actually do have the answer! :) ... The variable will populate the template with whatever value is stored in the database. In case of request status, the value we store is status.* where * is either open, onhold, resolved, etc. So it will display like this... However, if you want your own (custom) text displayed instead of the database value (for "status.open" have "Open" displayed) you need to use the ESP conditions. Here is a quick overview of how they work: https://wiki.hornbill.com/index.php/Email_Templates (scroll down to "ESP Conditions" section). Give them a try... if you struggle with anything just let me know ;)

Link to comment
Share on other sites

Perfect! :)

I had a quick look at the wiki, and looking at the examples, I see that none of them actually show an example for string (character) comparisons.. only numbers (e.g. 0, 1...)... :(

So, when doing string comparisons (such as staus being "status.open") in the expression, both the variable and the value need to be enclosed in quotes or apostrophes... (not just the value). Like this:


It is a bit unusual if you're familiar with how a code works...

To cater for all possible statuses, just chain them one after another. Because, as mentioned in there, "the variable will only be displayed if your expression is found to be true". And since there can be only one possible value you will have only one condition displaying its value. Hope this makes sense :)

Link to comment
Share on other sites

9 minutes ago, Drew Davies said:

same functionality within the ticket summary/descriptions when updating via the business process?

uh... a bit vague :) ...sorry, do you have an example so I am sure I understand correctly what you would need (on the BP side)?

Link to comment
Share on other sites

16 hours ago, Drew Davies said:

have the summary/description text be conditional according to various inputs in a single Automated Task without requiring a decision tree before hand

ahh ... I see... well that would be a no, I'm afraid :( ... "text to be conditional" would require some sort of functions or code in node design but we intentionally did not implement such functionality because it would make BP design too technical and non-tech users might struggle to understand or build such nodes... we try to keep it as simple as possible even if that means a more laborious BP design at times :( 

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...