email routing rules - best format for emails to be in when put into a service request?

[Adam Toms]

Hi all,

I've looked at the wiki documentation surrounding routing rules, and I'm trying to work out what is the best format for an email to come in using a routing rule, and then a request is raised.

The email has lots of text in it, and when it goes into a ticket some of the formatting is lost in the description. I appreciate configuration around routing rules can be limited. But is there anyway when the source email that comes in from a routing rule that the formatting of that email can be enhanced when it enters a ticket?

The email in the mailbox does display correctly but when the information is placed into the ticket, information in bold is just in plain text. The source format for this particular email is HTML.

Many Thanks

 

[Steve Giller]

The information recorded in the description of a Request raised via the Auto Responder functionality is always the plain text content of the email.

 

[Adam Toms]

Thanks @Steve Giller for your reply.

A lot more email traffic than it used to be is now being sent in HTML format. Do you know if there could be a way for the auto responder functionality to include HTML, as well as plain text? 

Or because of the nature of the information going into the ticket, will this only ever be handled as plain text, and therefore the best outcome to respect any formatting in the email, is to have the source email when linked to a routing rule is to be sent in plain text as opposed to HTML?

I'm currently working on project trying to marry information one system into Hornbill, and as I've been engaged at the 11th hour. I'm limited in my options other than the email routing rule, and because of the same issue, I'm limited on what I can get changed at their end, so I'm just trying to work out the best way forward.

Many Thanks.

 

[Steve Giller]

This isn't my area of expertise so please excuse any inaccuracies, however to the best of my knowledge:

All email is, at its heart, plain text.
Additional features, such as formatting, are sent as an additional layer for clients that are capable of displaying them - the plain text can be sent without the formatted version but the formatted version cannot* be sent without the plain text version, and there are still numerous plain text clients in the field.

There are a number of reasons that the plain text version are used, the best practical examples are that:

• The Timeline is formatted by wiki markup, so HTML is meaningless and could be unreadable, and
• The BPM can use the source email, but you'd have no way of catering for HTML, let alone the quirks of email editors - branching on Description Contains Critical error would not branch on Critical&nbsp;error or <span style="color:#c0392b"><strong>Critical</strong> error</span> for example.

Additionally, HTML is a potential attack vector, so using the plain text is more secure.

The original email is always available via the View Email option on the first Timeline entry if required.

*well, it can, but it's breaking the standards if it does.

[Adam Toms]

Thanks again Steve, much appreciated.