Automation description

[Timi Falusi]

I have an automation that copies details from a ticket in project and creates a ticket in another project with all the same details. Is it possible to have it also include lines in the description like:

"Issue:

Root Cause:

Resolution"?

[Darryl Lee]

Hi @Timi Falusi - yes you can accomplish this with the use of Smart Values! Here's what that would look like:

You can also use Smart Values for other fields, once you Choose them from the drop down.

[Timi Falusi]

Hey so I actually want to do this for all the tickets when they are created in a project to have these automatically 

"
Issue:

Root Cause:

Resolution:
"
Do I just create an automation in the project with the image you attached?

[Darryl Lee]

Ah, so what you're talking about now is a template, or default text. 

Ideally you'd want your text to show up as soon as somebody clicks [Create].

The Automation I gave you will simply append it to whatever they already entered into the Description.

This is a long-standing problem with Jira - they let you set default text for custom fields, but not for a system field like Description.

Unfortunately there's not a great solution. We pay for third party tool, Issue Templates for Jira that after you select a template, will populate the fields (including Description) with whatever text you want.

I'm sure there's other third-party tools, but yeah, no way to do this without paying for something. (I suppose it might be possible to build your own Forge app to do this, but I've not explored that.)

[Darryl Lee]

Ok, I forgot that a long-standing workaround is to create a "Custom Description" field and display that field (instead of the "real" Description field) on the Create screen with default text, and then using Automation or a Post-Function, copy the value of that field to the "real" Description and hide the "Custom Description" in all other screens. This is described here:

• Default text for Description field on Jira Cloud 

In that same answer, @Matthew Rochman brought up some gotchas to be aware of:

Second, it creates a problem with cloning tickets (a native Jira functionality)

We had a situation where there are 'repeated' tickets on a monthly basis and cloning and slightly tweaking last month's ticket is all that's needed. If you clone a ticket with that post function on create, it will overwrite the description and copy in the description as it was when the source ticket was first created.

Also - I think the solution might be fine for some, but if you start doing integrations with third party systems that create tickets automatically in certain scenarios, this post function will cause headaches as it applies whenever a ticket is created.

[Darryl Lee]

Ahh, @Trudy Claspill answered this far better than me last year:

• How to add a standard text in the description field when creating new task 

Notably, she points out:

If you are using a Team Managed project, you can set a default value for the Description field, and that value will show when you are in the Create dialog.

If you are working with a Company Managed project it is not possible to set a default value for the Description field without a third party app like ScriptRunner or Default Values for Create Issue Screen

And she links to an additional answer/discussion of the same workaround above involving a Custom Description field:

• How to create a template for issue description? 

[Timi Falusi]

Thanks!

[Darryl Lee]

OH wow, I was not familiar with this add-on that Trudy mentioned, nor have I used it, but it appears to be built for this one thing, the reviews are solid, and it's pretty cheap:

Default Values for 'Create Issue' screen - Issue Templates 

[Olga Cheban _TitanApps_]

Hi @Timi Falusi !

I would recommend solving this with the help of templates rather than Jira automation rules. Although Jira doesn't allow you to create issue templates with a pre-set description and other details, this can be done with third-party tools, such as our solution Smart Templates for Jira. It enables you to save any work item (or a set of work items) as a reusable template.

You can mark your template as Global - in this case, it will be available across multiple projects in your Jira instance. 

Here's an example - a standard Bug Report template that we use across projects. It outlines the key steps and contains placeholders for standard information input:



For more complex use cases, smart templates can also include subtasks, checklists, and more. 

Once you have such a template, you can schedule automated ticket creation with a native Scheduler. It's also possible to use templates together with Jira's native automation rules (please see more details in our Automation Guide).

I hope this helps!
Let me know if you have any questions

[Akash Singh]

@Timi Falusi Could you please share a screenshot of the automation action you’re using, or describe which action is currently configured to create the cloned work item?

Additionally, can you confirm whether you want this text to be appended to the existing description of the cloned issue?

[Timi Falusi]

Hey so I've had a change of mind and actually want to do this for all the tickets when they are created in a project to have these automatically 

"
Issue:

Root Cause:

Resolution:
"

[Akash Singh]

@Timi Falusi In addition to the workarounds and solutions already mentioned by @Darryl Lee, you could also build a lightweight app using Forge’s UI Modification module to dynamically update the Description field on the issue create screen and deploy it to your site. Once deployed, the end result would look something like the example shown below.

You can refer to this recorded session on UI Modifications to learn how to build a similar solution:
https://www.youtube.com/watch?v=2cjWkEUJTnw

That said, I would ultimately recommend using an existing third-party app already available in your organization, or alternatively a separate text-type custom field, whichever option is easier and quicker to implement.

[Darryl Lee]

OH thanks @Akash Singh !

I was wondering how the app Default Values for 'Create Issue' screen - Issue Templates is doing what is doing, and this is probably how!

I found the section of the video where Marcin specifically talks about creating a Template: at 15:58. 

Alas I don't see that in the sample code that is linked. @Marcin Konopka ϞϞ_๑_ __ _๑__ do you think you could drop a link to that? Whatever repo includes the templates.ts would do the trick.

The nerd in me is intrigued.

But the admin in me says NO!

Unless you have Node.js experience or you've got Node.js developers on your team or in your company and have some spare time to learn Forge, I agree with @Akash Singh that getting an app or using the "Custom Description" workaround is a better, and most importantly, more MAINTAINABLE approach.

Because even if you or your team codes this up, well, you'll probably want a better UI than having to edit Atlassian Documentation Format in a Typescript file if you ever want to update the template. (Also, Typescript!? Ooof, I don't even know Javascript!)

And god forbid Atlassian change or deprecate any of the methods used here, because then you'll have to update your app to support the new methods and redeploy the app.

[Akash Singh]

@Darryl Lee I couldn’t find the template either, but you can use the same template that’s demonstrated in my example here:
https://gist.github.com/kashsingh/0f486ec8c6a510710efc1a2fb5be8ca3

Also, you don’t need to create the ADF directly. My usual approach is to first design and refine the template within a Jira work item. Once I’m happy with it, I extract the ADF using the Get Issue API endpoint.

That said, I do agree with your point, this approach is harder to maintain. You need to stay vigilant about any upcoming changes to the Forge platform or Atlassian APIs that could impact the implementation. With alternative approaches, much of this risk is effectively offloaded to vendors or Atlassian.

Additionally, there’s no guarantee that the next person who takes over this setup will be well-versed in the underlying technology, which can create a strong dependency on you to keep the environment running.