How do I pre-populate text to a description field on JIRA Cloud version 7.x?

I have tried all the Javascript solutions I've found already and they only seem to add the code as txt to the grey'd out area beneath the text box (like a label).

9 answers

Comments Closed

Let me start ny chiming in with _all_ the other user that have (or have had) a positive experience with pre-populating the description field.

My google-foo led me to this thread in pursuit of solution to the exact same problem.

The technical term for this kind of behaviour from the system is actually a very established concept, it's called NUDGING:

In stead of _forcing_ users to waste time populating multiple fields (that will not later be used for structured queries), it's much more elegant (and effecient) to nudge users to remember to add the relevant information (or delete the template-generated content…).

Come to think of it - It's ___exactly___ the same methodology that's already being used elsewhere in other Atlassian product, EG.: "Confluence":

When you're using the templates for EG.: Meeting Notes, you see pre-populated text that you should replace or delete:

  • "Set goals, objectives or some context for this meeting…
  • "Type your task here…

I wonder why it's a great idea there, but not in JIRA… :-)

PS.: I must say that in the cases where this does NOT work, it must be the _people_ using the issue-tracking-system that are in need of guidance.


NB.: I added that behaviour when using bugzilla many years ago and it worked brilliantly.


So please focus more on HOW to achieve it - as opposed to only argue WHY NOT to do it.

A helpfull nudge ;-) regarding why it might be considered bad practice is OK, but completely demeaning any other ideology is counter-productive

Brilliant answer. Not allowing a default value for a field, it does not matter how do you want to justify it with cheap philosophy: it is just wrong.

And yes, some people here are willing to use the default text as a placeholder, because Jira does not support that either.

It is just wrong that the "description" field is a magical field different than other fields which accept default values.

Excellent answer!

5 votes
Ignacio Pulgar Community Champion Aug 23, 2015

You can do it by creating custom fields.

In order to do so:

  1. Enter JIRA, press the 'g' key twice and type 'custom fields'.
    1. Click on the button 'Add Custom Field', on the top right corner.
    2. Select a text field (multi-line or single line). Click 'Next'.
    3. Give it a name and, optionally, a description.
    4. Click on Create.
    5. Select the project(s) checkboxes in which you want to include your custom field.
    6. Click on Update button.
  2. On the Custom Fields page, find the name of your custom field and click on the icon in the right > 'Configure'.
    1. Click on the link 'Edit default value'.

    2. Type the description you wish to be populated as the default for that given field.
    3. Click on the 'Set Default' button.
  3. Repeat this process again for each text field in which you want to have a different default value.

After that, associate your custom fields to the screens in which you wish to have them.

3 votes

Essentially, you can't - javascript hacks in JIRA are gradually being disabled, and the approach here is to get a good answer to "why are you trying to put useless data into fields?".  What are you trying to achieve by pre-populating the description?  Why haven't you split that up into custom fields which do take defaults?  What use is a description people will just accept instead of putting good data into?  Why don't you just remove the description field if you're not going to ask people to think about its content?

Because it isn't pre-populating that actual data rather the information for the standard answers that need to be given on each issue that is filed.  It is basically a template that MUST be filled out on every ticket.  A gentle subtle ... in your face reminder of what is required to be in that field.

Ah, all the wrong answers as usual. If you pre-populate a text field, people will ignore it. If you need it to fulful a certain format, people will overwrite that too. Convert it to a set of fields, leave them blank (unless you genuinely do have solid defaults for them) and set them mandatory to force people to enter them and think about it. In places where people set text defaults, you find that between 60% and 99% of issues will have the defaulted text and nothing else (the more complex you make it, the higher the percentage as a general rule).

We use Bug issue types.
I want my testers to enter a standard format for bugs in the description of the bug. I don't want to add another custom field for something the Description of the bug should handle.

You cannot do this is acceptable.

You shouldn't because my arbitrary experience tells you not to isn't always acceptable. 




This should be available in Cloud version.

Same answer - you're going to get large amounts of pointless rubbish if you try to inflict this on users.  Consider doing it properly.

Trying to force users into populating many mandatory fields that are mostly - but not always - applicable, is a surefire way to make users enter pointless rubbish while cursing the stupid rigid form at the same time.

Pre-populating the description field, with a useful, helpful template that both reminds users of what they should be writing and assists with nice formatting works great because it actually makes the work of the user easier while still allowing the user to use a better format in special cases.

I know it works, not from personal opinion, but from personal experience with a team of software developers that I was leading. We used Default values for create issue screen which unfortunately isn't available for Cloud, only for Server.

Nic, you are entitled to your opinion, but don't presume to know every situation that Jira users have better than they know it themselves. Scriptrunner is great, BTW.

I have to respectfully disagree with you, Nic. I have been using the prepopulated Bug format listed above for years and both the testers and the developers love it. I've only had a few people overwrite it and correcting them was a great teaching opportunity. 

I'm working with a client now that is having a lot of trouble remembering the User Story format "As a ___, I want to ____ so I can ____". I was hoping to prepopulate that into the Description field for them. 

All I can go on is my experience of finding tens of thousands of stories with nothing by the default text in them.  In some places, it might be fine.  In the places I've seen, it fails.


What are you trying to achieve by pre-populating the description?
I thought I was clear, maybe I wasn't.

We want the description field to be more guided to help adherance to convention.

We like the description field being a single searchable discrete field. Most users follow the format, but it would be great for training and onboarding to have an established format for them.

Why haven't you split that up into custom fields which do take defaults?  
See above.

What use is a description people will just accept instead of putting good data into? 

I don't think you read, or understand what I described. Each bug is unique. However the very basic outline of: 

Steps to reproduce:

Expected Result:

Actual Result:

The format above is already  being followed, but some users forget some times and new QA users have to be onboarded.

Why don't you just remove the description field if you're not going to ask people to think about its content?  


That is one option. We're already functioning well and sufficiently, but I would like to improve and enhance our current workflow.
If this isn't the forum or place for these types of inquiries, could you please direct me to them?



No, you're in the right place.  I think we've covered your recent comments already.

In the end, is it possible to do (Cloud version) as outlined above by Ryan Thomas? :

Ie set some deafult structure/guided description body that users can follow?




No, it's not possible on Cloud, you can't inject the code.  Do it properly, with separate fields.


the same as guys above, I have exactly the same need.

Pre-fill template while creating bugs:




I am one of many of Team leaders who really APPRETIATE if JIRA  allows us to decide which way is more suitable in our environment.

We do have separate fields for Environment, operating systems, type of tests and others. But there is essential need of pre-filling description field with a template of what-you-should-not-omit-if-you-are-describing-what-was-wrong.

Nic, I am very sad of you attitude. We don't want to inject code. We want the ability to pre-fill the description field. If there is an option in the field edit mode, it would be the best solution.

Your proposal maybe works from developers perspective, but absolutely doesn't work from team process perspective.
Let Jira is tool and we master the processes. Not in opposite.


Same answer - JIRA doesn't do this natively, so you have to hack it.  I'm afraid for Cloud, there's no real way to do it, unless you start doing things with browser add-ons.

I'm glad it doesn't let you, because it's a bad way of doing things, simply because you end up with a lot of junk and defaulted values, but that is a different discussion, and explained in full above.

I just wanted to chime in here and say that in 3 separate companies I have introduced pre-populated fields and have not experienced the 60-99% problem Nic describes.

It works when your users see this as a time-saving measure that is there to make their lives easier, and they understand why you want bugs or stories to be written in a specific format. It doesn't work if you have untrained or disengaged people entering tickets.

On the whole, in companies with up to 100 JIRA users, this has worked. Where 'stories' and 'BDD acceptance criteria' were not relevant, we introduced a 'Chore' or 'Task' issue type that didn't have anything prepopulated.

From experience, hhere are the downsides to having separate fields and making those mandatory (something I have tried without success):

  1. It means each ticket takes longer to scan, meaning your organisation is less efficient as a result.
  2. It adds a lot more to the initial JIRA setup time (fields, workflows).
  3. It adds unjustifiable bloat to maintenance whenever you make significant changes to workflows (now you have to manage 3-5x more fields and for which transitions they are required instead of just one).
  4. It's confusing to the average person: people often don't understand why every ticket needs to have 'X' field, even if you put error messages in.
  5. It replaces a low friction reporting process with a high friction one: if you can edit a single piece of text it generates less cognitive load than being asked 3 or more different questions requiring non-specific answers. It's the same reason online checkout abandonment is higher when there are more steps to the process.
  6. It encourages (much more in my opinion) unuseful values as people type any old junk just to fulfil what they consider to be an arbitrary field requirement in a transition.

Basically, by insisting on 'hard compliance' through hoop-jumping instead of 'soft compliance' through guidance, you remove flexibility and make your reporting process less Agile and less efficient. Somewhere, the person managing the database can run a report where everything fits neatly within the lines, but overall the organisation suffers.

My 8 years of experience with managing JIRA across 3 organisations has taught me there isn't one 'true' way to do things. You need to figure out what works best and be flexible to meet the demands of the whole organisation, not just one subset of it.

In this case Custom Field defaults should serve nicely.

Really sad to see this blanket statement answer over and over without considering why people do it. I'm in the same boat, I want to make it easy for my users and gently remind them of necessary information. Nobody in my organization wants to battle with a complicated form when all they need is a few lines of text in a text template.

We do the same with our GitHub pull request templates: We have some pre-populated text that reminds the submitter to fill in information that makes understanding the issue much easier.

I'm not sure it's fair to say the reason people ask is not considered - I think it is, and I think we do mostly understand why people want to do it.  There's not a lot of discussion on it, because the "why" is not the issue.

The discussion has spent more time on the problems it causes and why people like me have spent so much time cleaning up the mess it tends to make.

Nic - I think it's time to maybe consider that in this case you might be wrong. I mean, really consider it. Is it possible that your reaction, based on your extensive experience, is not actually relevant to the suggestion that people are making? That there's a use case here you haven't seriously considered?

In my 20 year experience with software project management at numerous Silicon Valley companies, there is no single step which is more conducive to good bug reports than the exact template that keeps getting mentioned in this thread:




There's a reason so many people use this. It works.

Now I'm willing to be open minded too. Can you propose a design using custom fields or other available features in Jira to accomplish the same result without a default template for Description field? That when a issue is filed with type Bug, that the victim of the bug is gently nudged to structure their bug report in a way that is clear, systematic, and comprehensible to both developers and testers? That this structured observation still provides enough flexibility for users to bend it to their needs and the idiosyncracies of each bug, or ignored if it doesn't apply at all? And it is presented front-and-center where everyone who looks at the issue will focus on the most important characteristics of the bug? I am legitimately interested in your answer.

I'm afraid you need to read the rest of the conversation.  It's all covered there already.

I agree with @Martin Unsal - we have a need for this as well. Unfortunately we're using the cloud version, so it seems there are no options available.

I'm really surprised, given the robustness of JIRA, this isn't an option that's available. 

Allowing pre-populate fields helps people entering bug or issues according to a template. This also reduce the possiblity to forget something (though specific fields do as well). 

On my side, one of the reason I would like that possible is because I work with populous teams that have minimal knowledge of Jira and I would like them to be able to search by keywords in the summaries and descriptions to prevent duplicates; the information exploded in numerous fields makes that impossible. 


I want to do the same thing as other people have mentioned on here. Pre-populate the description with a template structure 

Steps to reproduce

Observed behavior

Desired behavior

Hopefully someone will see that there are several people here that desire this functionality, and help us achieve it, rather than beat us over the head with their opinions about custom fields.

As before - JIRA doesn't do this natively, so you have to hack it.

I'm afraid for Cloud, there's no real way to do it, unless you start doing things with browser add-ons.

Custom fields are your only option, irrespective of any opinions.

Put the following in the Description field and it does the trick. Ticket quality has improved substantially

I followed the basic from here:

but used the following code.


<script type="text/javascript">
if (document.getElementById("description").value == "")
var template = "*Steps to Test / Reproduce*\n"
+ "# goto\n"
+ "# [step 2]\n"
+ "# [step 3]\n"
+ "# [more steps as needed]\n"
+ "Replace this text, you can use attachment tool to inline screenshots\n\n"
+ "*Desired/Expected Behavior*\n"
+ "Replace this text\n\n"
+ "*Observed Behavior*\n"
+ "\n"
document.getElementById("description").value = template;



One user mentioned it already, but here's the link:


Using "Behaviours" from the ScriptRunner plugin should exactly solve this request.

Again, bad idea, and it's not valid for Cloud.

This does not work. It actually makes the problem even worse.

It does add a pre-filled description on creation of the issue.  After you create it.  Every issue done this way has the default text in the description, and users have no reason to go back and edit it.

Jira/Atlassian does not allow it because they want people to use more add-ons in the cloud version. People like Nic who work for add-on vendors try to convince that jira is doing the right thing as it is an opportunity for his company to sell plugin like script runner addons.
There is no point discussing as nothing will change until another competitive product alternate exists. It is capitalism.

No, people like Nic are tired of cleaning the mess made by this sort of poor design.  I'm not trying to sell anything.  In fact, if I were, I'd be encouraging you to do this because I know it generates "please clean up the mess" work for people like me.

Sonik S I'm New Here Nov 28, 2017

You are funny Nic. And thanks for your dedication to the forum. May be we can all use your help to lobby Atlassian for the good causes. Do you still work for Adaptavist?

I will need to move to the server version for this functionality. Well if this is the case and users are given helpful nudges or hints on what and where to add necessary information I see no downside.  

Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,269 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot