Jira smart value {{issue.description}} not fetching the issue description in auto email

[Shreyash Kulkarni]

I have created an automation rule

It will be triggered when issue is transitioned to Done status - the rule will crosscheck the issue type and component and send an email.

All the smart values return the content except the {{issue.description}} one. What could be the reason?

Ive tried adding the description while creating the subtask itself but it still doesnt return the ticket description.

Please let me know what else I can try and what could be the reason.

Update - for anyone facing a similar issue, please check if there exists a custom field with the same name in your project and swap the jira smart value with {{issue.customfield_10xx}}

[Jack Brickey · Accepted solution]

The "description" field in the subtask is a custom field while the "description" field in primary issue types are system fields . While you can successfully use {{issue.Description}} for primary issues you need to use the Custom field ID {{issue.customfield_10xx}} for subtasks.

[Jack Brickey]

Hi @Shreyash Kulkarni , it should work. Dumb question...is the description field blank? Can you add a log action to your rule and log the {{issue.description}} then check the audit log results?

[Bill Sheboy]

Hi @Shreyash Kulkarni 

Adding to Jack's questions:

For a question like this, please post images of your entire automation rule, the specific action (without extra highlighting/annotation), and of the audit log details showing the rule execution.

Those will provide context for the community to offer ideas.  Often where in a rule actions occur impacts behavior and so seeing the images may help.  Thanks!

And also...what type of project is this: company-managed or team-managed?  Have you checked if there are multiple fields named "description" leading to a problem with the smart value resolving correctly?

Kind regards,
Bill

[Shreyash Kulkarni]

Hi, @Bill Sheboy . Thanks for your thoughtful guidance. It is a company-managed project.

Here is the entire automation rule.



Here is the subtask description and comment

@Jack Brickey I have added log action to the rule and checked the audit log.

[Jack Brickey]

Thanks for the details @Shreyash Kulkarni

I note that your email component uses Summary. Does that work? Does the email have the Summary? The log component references Description and is blank which, unless the Description is indeed blank, has me scratching my head. It works ok for me. At this point I would suggest the following actions:

1. attempt a simple test rule in another project: trigger manual, action comment add description to comment
2. failing the above, contact Atlassian support

@Bill Sheboy , any other observations/ideas?

[Shreyash Kulkarni]

Hi, @Jack Brickey 

Every value below is getting fetched except {{issue.description}}



The description has not been blank in the issue ticket almost dozen times I have tested this rule but it is blank in the email.

This is the auto mail

I will try running a similar rule in a different project.

[Jack Brickey]

Quite odd. Seems like a bug to me. If you contact support please update us here.

[Bill Sheboy]

One more thing to try...

Rules can get "broken" due to to many edits, problems publishing, etc.  I have no idea why this happens.  The check for that cause is what Jack suggested earlier: disable this rule, create a new rule with the same steps, publish, and test.

If that does not work and you contact Atlassian Support, please post what you learn from them.  That will benefit the rest of the community with the info.  Thanks!

[Shreyash Kulkarni]

Hi, @Bill Sheboy @Jack Brickey 

I contacted Atlassian support and my issue is resolved.

@Bill Sheboywas right - the "description" field in the subtask is a custom field while the "description" field in other issue types are system fields which is why this automation rule was working with story issue type but not with subtasks.

I tried the automation rule with the modified smart value {{issue.customfield_10xx}} and it worked!

[Jack Brickey]

Thanks for the update @Shreyash Kulkarni . That is certainly news to me, I.e. that Description isn't a system field for sub-tasks as it is for primary tasks. But good to know for sure.

With that said I need to better understand when you can use a Custom field name in a Smart value and when you must use the custom field ID (customfield_10xxx). @Bill Sheboy do you happen to know? I have been meaning to research this.

@Shreyash Kulkarni , I am going to separate out the tru answer her so it can stand out on its own rather that the entire troubleshooting dialog.

[Bill Sheboy]

Hi @Jack Brickey 

I welcome input from the Atlassian team on my observations below...

My understanding is the custom field, human-friendly smart value and custom field id  smart value can be used interchangeably in rules.  A couple of challenges with these:

• Custom field names which contain non-alphanumeric characters sometimes appear to have smart values requiring surrounding quotation marks and sometimes not.  I hypothesize this can also vary based on the automation feature used.
• What exactly is the "human-friendly smart value"?  Smart values are name, spacing, and case-sensitive...sometimes but not always.  ;^)

It appears there are at least 2-3 names for a field:

• the displayed name on any views / screens
• the human-friendly smart value (This could be the same as the one above.)
• the custom field id smart value

The first one can be found in the field configuration views.  The last two can be found using this how-to article, as it indicates which smart values are supported by automation rules: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-issues/  Note there could be other smart values, but they may not be supported by automation rules.

Regarding "at least 2-3 names...", there are definitely fields which have some apparent legacy shenanigans happening, such as "Due Date".  My hypothesis is such fields had different names / implementations over time, and so have several alias names.

Add to that there is no uniqueness requirement for field names (sometimes worsened a bit by team-managed projects and new Jira features).  Which is why I always experiment with new custom fields before I assume a rule works as designed.

Kind regards,
Bill

[Tomáš Vlach]

Hello @Shreyash Kulkarni 

is there possibility that there are another smart values in the actual body of the description?

Tom

[Shreyash Kulkarni]

Hi, @Tomáš Vlach 

There aren't any smart values in the actual body of the description.