While testing Jira Service Management we noticed glitches in:
We guess these would affect CSM also, and perhaps affect email processing for Jira generally.
I would really like to:
Has anyone using JSM documented what formats work and what to avoid? So far it looks like:
@Dwight Holman , understood, and that changes the advice: if the portal is out and the customers are Outlook desktop, the document has to survive as email, so the rule becomes "tables that Word's engine renders cleanly." In practice that is: no merged cells, no cell colours, four columns or fewer, one line of text per cell, and a plain header row. Time sequences fit that shape if each row is timestamp, event, owner, and nothing wraps. Anything that needs more than that (a long narrative per step, nested detail) goes in a second table below rather than a merged or coloured one, or in a PDF attachment, which is the one rich format that arrives identical in every client. Thank you for testing it against Outlook rather than guessing; that is exactly the evidence the four tickets need, and I have voted on them.
Hi Dwight, great list, and it's worth turning into agent guidance. A few things I'd add to your test matrix and your "avoid" list:
For the agent-facing guidance, a simple rule has worked well for me: in customer-visible comments use only paragraphs, bullet/numbered lists, bold and links. Anything tabular goes in an attachment or a KB article that you link to. For the customer KB page, a short "why your email may look different" note, plus a portal link to view the full formatted request, covers most cases.
Voting on and watching the four tickets you listed is still the best way to get the root causes fixed.
Hello @Dwight Holman
Your list looks right, well theres nothing really to add to it.
Best,
Arek🤠
@Dwight Holman , the list is right and @Josh "paragraphs, lists, bold, links" rule is the one I give agents too. One addition for the two documents you want to write, because it changes what you tell people.
The mechanism, in one line, for the KB page: every customer email goes through two lossy conversions, the agent's rich text (ADF) to email HTML on the way out, and the customer's email HTML back to ADF on the way in, and each mail client adds its own third one. Nothing in the middle is a bug in your configuration; it is the format changing hands three times. That sentence stops agents trying to "fix" it with more formatting.
The escape hatch, for the customer page: the portal always renders the agent's comment as written. So the customer notification templates should carry a plain sentence with the portal link near the top: "If this update looks wrong in your mail client, open it here:" followed by {{issue.url.customer}}, which resolves to the request on the portal. That one line means a mangled table costs the customer a click instead of a reply asking what you meant, and it is the same sentence whether the client is Apple Mail, Outlook desktop or Gmail.
{{issue.url.customer}}
For the agent guidance, the corollary is: anything tabular or heavily formatted is written for the portal, and the email is treated as the notification that it exists. Once agents think of email as the alert and the portal as the document, most of the traps on your list stop mattering, and the four tickets become nice-to-fix rather than blockers.
Thanks for the helpful advice. For my team, tables are regularly used to narrate real-time sequences for a specific issue, so we cannot simplify quite as much as you suggest.
For a number of reasons, we do not plan to use the JSM portal. It lacks important features we need, and (for other reasons) we expect our customers will continue to be email-centric.
This means these issues will impact us and our customers - though hopefully at a low frequency.
I accept that these are lossy conversions, but after testing I think Atlassian could do better.
Thanks for the helpful advice. For my team, tables are regularly used to communicate time sequences for a specific issue, so we cannot simplify quite as much as you suggest.
Based on our tests it is clear: Atlassian could improve these conversions.
Thanks Josh - will add some of these to my list.
Indeed most of our customers are corporates - so Outlook Desktop is probably one of the big email clients they use.
It looks like you're new here. Sign in or register to get started.
