nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Description Field Formatting From Automation

Matthew Morris_37vmsi

Does the description field in Jira Product Discovery work with the Jira Text Formatting Notation that can be used in Jira proper? When I add an `h1.` or even some *bolding asterisks* they just show up as plaintext in the description.

Is there a way to format a description if it's coming in through an integration or automation?

For context, I've set up a Slack workflow to create an Idea. Everything is coming over great with the exception of the description not formatting. I've tried to add the Jira text formatting notation to the description but it only comes over as plaintext.

Thanks for all the help!

Accepted answers

Walter Buggenhout

Hi @Matthew Morris and welcome to the Community!

Jira cloud's editor has evolved quite a while ago and does not support markdown anymore the way it did in the old editor and on the server platform.

There is a (long standing) request to bring back this capability that you can track here: JRACLOUD-72631

For the specific examples you shared, you could try to use the following alternatives, as the editor is still capable of replacing (different) into text styles:

# Heading 1

## Heading 2

**bold**

For a more extensive list of markdown syntax you might still be able to use, see this support article.

Hope this helps!

All comments

Walter Buggenhout

Hi @Matthew Morris and welcome to the Community!

Jira cloud's editor has evolved quite a while ago and does not support markdown anymore the way it did in the old editor and on the server platform.

There is a (long standing) request to bring back this capability that you can track here: JRACLOUD-72631

For the specific examples you shared, you could try to use the following alternatives, as the editor is still capable of replacing (different) into text styles:

# Heading 1

## Heading 2

**bold**

For a more extensive list of markdown syntax you might still be able to use, see this support article.

Hope this helps!

Matthew Morris_37vmsi

Thank you for the reply! I did try both the `h1.` and the hashtag(s) for headers but neither worked.

If I do an import in the cloud editor it can still handle some bits of the Jira notational version of markdown but sending it over through an integration or automation didn't seem to work.

Bummer that it seems like this isn't going to be possible. Thanks for the link to the Jira ticket though!

Matthew Morris_v0ytef

Coming back to this a few years later. New company. Same problem.

But I'm back with a solution that worked for me this time! Combo help between Rovo & Claude.

The description field in Jira Automation is ADF (Atlassian Document Format), not wiki markup. That's the whole problem in one sentence. Typing h1., ##, **bold**, whatever, straight into the Description field just sits there as plain text.

Here's the fix that I found. First, make sure to leave the `Description` field completely blank in the action itself. All of your actual description content goes into the Additional Fields box instead (More options > Additional fields), as a plain wiki markup string:

{
"fields": {
"description": "h2. Problem Context\nSome text.\n\nh2. Next Section\nMore text."
}
}

Jira takes that string and converts it into real headings and bold, server side, at creation time. It's the same wiki markup conversion Jira already uses elsewhere (there's a doc on converting wiki markup to HTML for outgoing emails that points at the same underlying converter), just triggered from a different spot than I expected. The two fields fight each other if you fill in both, so the visible Description box has to stay empty for this to actually take effect.

One thing worth knowing if you go this route. Once you've got smart values with quotes in them, the rule editor's own JSON checker may flag the whole thing as invalid JSON. Ignore it. The evaluation happens after Jira resolves everything inside the double curly braces, not on the raw text the editor is linting, and the rule runs fine anyway.

Wish I'd found this a few years ago, but hopefully it saves the next person the wait.