Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Default text for Description field on Jira Cloud

After much research, it has been made clear that we cannot update the main description field with default text.

So I now see that I will need to create a custom field for thus purpose.

I have created a custom field, I have given it my default text, I have even adjusted its location on the ticket creation screen.  But I'm struggling to get it to be correct on the VIEW page.

What I want: It should look & function just like the main Description field. I want this custom field to be in the same exact location as the main Description field (I will then remove the description field from view).

What I am seeing: The custom field is showing up in the top section with the status, labels, components, type, priority, etc.


I know there are plugins to help with this, but none of them seem to be compatible on the cloud (which is where I am).


Any suggestions?

11 answers



EDIT : You can now use Jira automation rules to make this easier. Please read Ryan's answer bellow. 



Just to complete Gabriel's answer, here is a use case I had a hard time with (but found a pretty clean solution) :

1. Click on "Create new ticket" 

2. I want to see "Description" field with prefilled text inside it (Create screen)

3. I want to see the final content inside the "Description" (View screen)

4. I want to see "Description" when I edit my ticket (Update screen)


The main contraint here is that Description is a core field in Jira, which cannot be touched at start of the workflow.


What I've done for a quick solution, is to add a "shadow" description:

1. Create a custom field named "Description", multiline text, with wiki render configuration

2. Replace the native "Description" by your custom "Description" in the Create Screen configuration

3. Set default value you want for your custom "Description" (the text which will appear when the modal opens)

4. Go into your workflow configuration, and at the first transition (for me it was a transition between first point and "To be implemented" state) add 2 post functions at the top of the post functions list (rank 1 and 2).

        - First post function : Copy value of custom "Description" inside core "Description"

        - Second post function : Delete content of custom "Description"

5. Configure your screens like following

        - Create screen : must have your custom "Description" only

        - View screen : must have the core "Description" only

        - Edit screen : must have the core "Description" only


This way, when you click on "Create", your ticket will have the content you wrote inside custom "Description" into the core "Description" and the custom "Description" will not be shown because there's no content inside it.

For the other screens than Create screen, you just have to use the core "Description" instead of your custom "Description", we don't need the shadow Description anymore once the ticket is created.

Hi, @Julien Rubiano thanks for the awesome reply.

Just did what you described, but with a minor tweak, since I had to name my custom field "Description X" otherwise the post function dropdowns would only display one "Description" field, making it impossible to select a source and a different destination.

After everything was set up, I just renamed the custom field back to "Description" and it works

Like # people like this

You are genius. Thank you!

Like # people like this


I tried following the steps described by @Julien Rubiano but I can't seem to understand from where I can configure steps 4 & 5 from his post.

I am new with configuring JIRA Cloud and I would really like creating templates for the description field. At the moment, with what I've done, I've created a new custom field, but it doesn't look the same as the original Description field (i don't have the menu for formatting the text):



Also, the texts that were previously in the description field are now gone.

Can you please help me?


Thank you!

I am trying to setup a JIRA custom field to appear on the create issue screen to look like the Description field and then when the issue to created to copy the value from the custom field to the actual description field. I followed @Julien Rubiano details but I can't get the post functions to work. The aim is to have a 'template' for the description field.

I have created the post functions as described on the 'create' for the transition. However the Description field never seems to get populated. It doesn't seem to matter what order the additional post functions are. Or if I try and write to a different system field.
Is there a limitation here I am missing?
I am attaching the configuration I have for the post function that is supposed to make the copy - I get the same result -ie. nothing gets copied no matter which renderer I use for my custom field.2019-11-06 16_47_45-Update Workflow Transition Copy Value From Other Field Function - Jira.png

@Ana Maria Manea sorry for the delay.


Post functions are available in your workflow configuration, when you click on a transition (the arrow beteween 2 status).

Here is the Jira documentation :

@Nick Foster I'm not really sure where's your issue.

To clarify : you first need to set a default value to your custom description field (like "Here is the description of your issue, please send all mandatory informations").

To avoid any confusion, lets say your custom description field is called "Custom description".

Now you have to parameter your "Create screen" with "Custom Description" instead of "Description".

Because "Custom Description" has a default value, it will be populated at creation.



Now you dont want to stay with "Custom description", you want to go back with "Description". That's where post-functions are usefull.

In your workflow, you take the first transition (between the big dot and the first status) and you create a post function to copy the value of "Custom description" inside "Description".

You create an other post-function to delete content of "Custom description", because you don't want it to be shown anymore.


You need "Custom description" in "Create screen" only, all other screens keep "Description", which has now the wanted value.


Don't hesitate to ask step by step if you're blocked.


@Nick Foster Did you ever resolve your issue? If so, can you share how?I am experiencing the same thing. All steps work (including the post function to clear my custom description field) except for actually getting the info to successfully copy into the core "Description" field. I tried flipping the order (clear then copy, copy then clear), as well are oriented the new post functions in different orders ahead of the native post functions, but that did not seem to work either.

I am adding the post function on the "create" transition, perhaps that is not the right transition to trigger?

@Mackenzie Hartung I had the same issue and realised that I had "Creates the issue originally" as the first post function instead of the Copy value of custom "Description" inside core "Description". Once I changed the order, it worked for me :) 

Hope this helps!  

Like Julien Rubiano likes this

@Julien Rubiano I've seem to have everything in its place but yet the original description field is not populating and the custom description field is not being removed.  below are SS of my setup.  Any help would be greatly appreciated


Screenshot 2020-05-01 14.02.20.pngScreenshot 2020-05-01 14.03.10.pngScreenshot 2020-05-01 14.03.17.png

@Efren Toscano have you configured the post functions to the top first transition (like the screenshot bellow) ?


@Julien Rubiano This is a sweet solution!  Thanks!

As a side note.  Since I wanted to have different templates for the different item types, I just created a set of "Bug Description Template", "Story Description Template", etc, fields and this way I could set the default value separately for each item type.

Like Rich Wolverton likes this

@Julien Rubiano I really like this solution and have it working.  But I now realise it doesn't work when you clone - it gives me an error "Unable to clear field" for my custom description.  And I think because Clone uses the same workflow as Create, this solution isn't going to work?

@Matt Stephens I skipped that step in my setup.  I don't clear out the custom field where I have my template text set up and I can clone without error.  I didn't really see a reason to clear out text in that custom field I'm never displaying again after issue creation, so I just didn't do it.

Like # people like this

ok @Ryan Cabanas that makes sense lol!

oh hang on though @Ryan Cabanas , it means the description on the clone gets replaced with the template as well right?  That feels like it could be annoying if someone actually wanted to copy the content.  I guess they could just copy the text before hitting clone, but would have to remember to do that.

@Matt Stephens Yeah.  You're right.

Like Matt Stephens likes this

@Matt Stephens Just an update for you.  You can work around the problem of "the Description from the original issue doesn't get copied over to the new issue after cloning" by using an automation.

The only downside I've found with the automation, though, is that when you are first presented with the new issue after the cloning completes, you don't see the updated "Description" field content in the new issue (which did indeed get copied from the original issue's "Description" field) until you manually refresh the page.


Like Julien Rubiano likes this

@Matt Stephens Ha!  I'm one-upping my previous approach.  :) 

You can get around the need for a manual refresh by using a webhook.  Set up your automation to trigger on a webhook.  Create a webhook that points to that automation.  Modify your workflow transition with another post function that uses that webhook and put it right after the "Creates the issue originally." post function.

Like Rich Wolverton likes this

Thank you @Ryan Cabanas from bringing some other clean solutions to this need :). I'll try the webhook I guess.

The main thing to remember with automation rules is the 1000 calls limit, because an automation rule is triggered even if there's no action to perform in your rule.

Hi @Julien Rubiano .  I believe that automation limits only apply when you set them up for multiple projects.  If you set up your automation for a single project only, there are no limitations.  (See the first reply in this thread.)

Like Julien Rubiano likes this
Connor Rising Star May 06, 2021

@Ryan Cabanas are you still using the automation/webhook for cloned issues? I just tested this setup without the post-function to clear the custom Description field, and without the automation/webhook, and the description field was cloned correctly. 

Maybe Atlassian has made a change to how cloning issues work, you might want to run a test to see whether you still need the automation/webhook.

Like Rich Wolverton likes this

@Ryan Cabanas I've edited my first post to link your answer, thanks for sharing this solution :)

@Connor I've tried it as you suggested (using just the copy field post-function and no automation/webhook) but end up with and empty Description field in the cloned issue. 

Hello @Ryan Cabanas 

Can you please provide more details about how to configure the webhook and the automation rule trigger?

Also, in this case, in the Creation transition -> Post-functions -> Will it look like this?


I tried what you suggested but it is not working on my side, can you please help me?



I have found the following steps to be the fastest way to default text to a predefined field when creating issue tickets from the backlog.


This has mainly been used with Bugs and Tasks but I am sure it is extendable to other issue types. The functions referenced are from the Jira Settings - Issues page:


  • Create a custom field and default the text
    • Create Custom Field
      • Select a field type - Paragraph
      • Name and Description
    • Use the newly created fields "Contexts and default value" to add the default text you want to appear in the predefined field
      • You do not need to associate the field with a context - use the default or a screen


  • Identify the "Software Simplified Workflow" that is used by the Jira project then copy and modify it
    • Workflows
      • List all the workflows used by Jira projects and identify the one that is used for your project 
        • Click Copy
          • Name the new workflow and use the diagram editor to view the workflow
          • Click on the "Create" transition, click the post function link, and add a post function
            • Use the "Copy Value From Other Field" function
            • Source - new custom field
              • It might not appear in the list so start typing it and it should show up as a selectable field
            • Destination - predefined Jira field
            • Add 
            • Move up the post function until it is the first in the list of actions
          • Publish the workflow if necessary





  • Add the newly created workflow to the Workflow Scheme for the project and associate it with the Bug Issue type
    • Workflow Schemes
      • List all workflow schemes and identify the one that is used for your project
        • Click Edit
          • Click Add Workflow and select the newly created workflow from the list of workflows
            • Click Next
            • Associate to Issue Type "Bug" and save
          • Publish the changes to activate the new workflow for the Bug Issue type on your project



I hope this helps.


I do agree with you, I did it in the same way and it works fine.

I only added an extra automation rule to cover the case when tickets are cloned



I hope this helps to robust the solution :)



Supremely thorough and helpful, @William Arnold.  This worked for me.  Thank you! One item to add.  The new custom field rich text paragraph that I replaced the default description with did not have a wysiwyg/editor for altering text, adding bullets, links, etc.  I found this article that was a simple fix for that.   

Like William Arnold likes this

@jcasarrubias Thank you for this solution!

Edit: for those who are unable to make this automation rule work, you need to use smart value {{issue.description}}  alongside variable name clonedDescription, and then in the last component Edit issue fields - set Description field value {{clonedDescription}}

Hello @Roman Balakin 

Good to know you have figure out how to use the automation rule :)

@Roman Balakin please would you share a screen shot of the automation rule with the placement of the {{issue.description}}, as this has not resolved my problem with the clone description being overwritten with the template that was presented by post functions.

One more simple yet effective approach. User fills an important part of description right there on issue creation. Automation adds structure. User adds other sections after creation.

One of our rules looks like this:

h1. Business Requirements
h1. General Flow
h1. UI
h1. Task Scope
h1. Definition of Done
h1. Out of Scope
h1. Next Phases


Please try the Cloud version of our Default Values for 'Create Issue' screen app.

You can set default values for Description (rich text editor included), Summary, Labels, Assignee, Priority fields.

Your feedback is welcome!


Hi All

I see a neat little trick that has been pointed out here and another post on same topic - creating a second description field and doing a post function on create to copy the contents into the real system description field. 

This does work and the logic seems sound, but this causes two problems: first you need to create the ticket, then fill out the details in long text field after creation. This didn't sit well with some users.

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.

I actually ended up just shifting out the system Description field and creating new long text custom fields like "User Story" and "Acceptance Criteria" and "Support Request Details", then using Jira's native default text feature to apply the template. It's clean and in the cloning scenario, you don't have an issue. This approach does present a problem when you "Move" a ticket to a project on a different screen scheme, but you can do some automation to sort that out.

My thoughts

It can be some kind of a browser plugin that detects that browser is on Create issue view and adds some text to Description field automatically. I guess it will be very valuable for QA. Anyone volunteers to create the plugin for Chrome?



Can I copy the template into the description without losing what's written in the first description field?


Do you mean, when you create a ticket? when cloned? or in which action?


So, when I create a ticket, I have both the description and the bug template field but when on view ticket anything I've written in the description field gets replaced with what's inside the bug template field and I wanted to combine both of them if I'm making myself clear. 


Thank you!

Hi @Julien Rubiano 


I got everything working but the clearing the custom field value... the post function i use does not seem to have an impact. 

I have got both post functions on top.. even before creating the issue.

any suggestions please?

I have even tried setting it to ".." or "-" but nothing seem to happen to the value of "Business Case"

Hello @wilfred.mathanaraj ,

Sorry for the late answer. Everything looks fine in your post function to me. Have you checked that your draft wokflow is published and that your project is using the correct workflow scheme?

If you want you can now use Automation rules in your project if you want, the UX is way better than post functions screens.

Hi @Julien Rubiano 

I made the set up to set value default in field description, just as you indicated, and it worked fine.

But I would like to set up a different value default for two different issue types (Story & Bug). I tried combining both issue types in the same post function, but only it worked with one, it depends on the position the rule in the list of post functions. Can you help me with this? 


Post Function.JPG

I have the same problem. Been trying to use different fields for each type but they are not removed when you switch type even if the only thing in them is the default text so it becomes messy very quickly. 

Hoping this can be addressed soon, we are really missing our server version!

@Kris Luhr 

I solved this by creating separate workflows for bugs and tasks.

Yes, we ended up using automation to set this up after create.

In our create dialog for bugs and stories (where we have templates) you can only input summary and epic.
So to create a bug is a two step process, but at least we have our template...

@Kris Luhr,  please will you share the automation rule that you use?

@Becci Watson sure, this is what we use for bugs: Screenshot 2022-08-23 at 16.27.29.png

as you see it runs after create for bug type issues, so when I create a new bug I enter a summary and possibly an epic and components (everything else is hidden): 

Screenshot 2022-08-23 at 16.31.19.png

When I hit Save I get a popup saying it was created where I can click to view the issue which now has the description filled with our bug template.

NB cloning will get the description overwritten as pointed out by others.

Thank you @Kris Luhr kindly for the fast response and sharing.

The Workflow Essentials plugin for server has an outstanding function, "Default Values for Create Screen".  It's super easy to use and allows you to specify a different default for each issue type in a project --- even if they're all using the same screens and schemes.

Sadly, it's not available for Cloud and I haven't been able to find an equivalent add-on or technique.

0 votes

Hi Alex,

You can try to use post functions to set up a default text on the Description field.

This post function would update the value of the field once the issue is created, for example. Using this, every time that specific type of issue is created, the Description is set with a default value.

In the below documentation, there are more information, regarding to using post functions.

That's an interesting solution.  However I'm looking to setup more of a template.

So each time you go to setup a new ticket, there are some default values in the description field meant to guide you on how best to fill out this field.  So this can't be populated once the ticket is created, but rather on the first screen when you are first filling out the ticket details.

Like Maksim_Feshchanka likes this

Hi guys, any updates if it's possible to create a default value for the description field?

Suggest an answer

Log in or Sign up to answer