Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

How to Automatically Pre-Fill Jira Forms with Work Item Data in responses

I want the form to open already pre-filled with the data from the Jira issue.

That’s it. That’s the whole request.

And yet… it turns out to be weirdly complicated.

Here’s the situation most of us run into.

A work item gets created automatically — maybe from an intake form, maybe from an API, maybe from automation running in the background. The issue looks good. Summary is there. Description is filled out. Due date, budget, custom fields — all neatly populated.

So far, so good.

Then the workflow hits the human step.

The issue moves to Review or Waiting for Approval, and now you need someone to confirm something. A manager. A stakeholder. A customer.

You send them a form.

And that’s when the friction starts.

The Blank Form Problem

The form opens… completely empty.

Even though all the information already exists in the Jira issue.

So now:

  • The approver retypes the budget.

  • The customer retypes the description.

  • The manager copies the due date from the email.

It feels unnecessary because it is unnecessary.

And if you're the admin, it gets worse:

  • You sometimes have to manually open the issue just to prepare the form.

  • You save it as a draft so it becomes shareable.

  • Your automation can send an email — but it can’t carry the issue context into the form.

The workflow looks automated on paper, but in reality, it breaks right before the important part.

Why This Happens

Jira Service Management forms are solid inside the portal.

Jira Automation is powerful.

But when you try to connect them in a dynamic way, you hit a wall.

Forms don’t automatically “know” anything about the issue when opened externally.

They don’t inherit data.

They start from zero.

There’s no built-in way to say:

“Take what’s already in this work item and show it in the form.”

So admins start digging into community threads about URL prepopulation, smart values, draft workarounds, and all kinds of creative hacks.

Because what you actually want isn’t just a form link.

You want a form that already understands the issue.

How to Make the Form Arrive Already Knowing the Answers

If your goal is:

When someone clicks the form, it should already be filled with the data from the Jira work item.

You can build that flow using Smart Forms for Jira together with Jira Automation.

Here’s what that actually looks like in practice.

Phase 1: Prepping the "Dynamic Receivers"

Inside the Smart Forms builder, you don’t just build fields; you build placeholders. For any field you want pre-filled (Summary, Budget, Due Date), you simply insert a placeholder like: {summary} or {budget}.

These fields act as "receivers." You can even hide them from the user's view if you want to keep the UI clean while still capturing the data in the background.Screenshot 2026-02-11 at 18.51.18.png

Phase 2: Zero-Touch Attachment

Forget saving drafts. Smart Forms allows you to:

  • Auto-attach forms based on issue type.

  • Generate secure URLs instantly. The moment the work item exists, the form is ready to go—no manual prep required.

Phase 3: The "Magic" Automation Rule

This is where the friction disappears. You set a trigger—like a status changing to "Waiting for Approval"—and use a standard Jira "Send Email" action.

By appending URL parameters to your form link, you’re essentially "injecting" Jira data into the form: ...&summary={{issue.summary.urlEncode}}&budget={{issue.budget}}Screenshot 2026-02-11 at 19.12.32.png

 When the stakeholder clicks, they don’t see a blank page. They see a personalized, pre-populated form that requires 80% less effort to complete.

Phase 4: Update Work Item Fields After Submission

This is typically the step where teams expect the workflow to continue — but in many setups, it doesn’t.

With Smart Forms, you can configure the form so that after submission it:

  • Updates work item fields automatically

  • Transitions the work item to the next status

In practice, this means:

  • An approval selection can update an Approval Status field

  • A confirmed date can update the Due Date

  • A revised budget can update a custom field

  • A CSAT rating can populate a Satisfaction Score field

  • An “Approved” response can move the issue to the next workflow step

This removes the need to manually copy values from the form into the issue, or to build an additional automation rule just to sync the response.

Instead of treating the form as a separate data collection step, it becomes part of the actual workflow. The submission directly affects the work item — which is usually what teams expect when they’re designing approval, confirmation, or survey processes inside Jira.

Where This Actually Changes Your Workday

Use Case The "Smart" Difference
Finance Approvals Approvers see the Budget and Project Scope pre-filled. They just hit "Approve."
CSAT / NPS The survey already knows the Ticket ID and Customer Name. Higher completion rates, zero confusion.
Change Management Deployment Dates and Impact Scopes are pulled from the ticket. Stakeholders just validate.
HR Onboarding New hires confirm Start Dates and Equipment that are already listed on the form.

The Bottom Line 

This isn't just about saving a few keystrokes. It’s about process integrity. By moving from static forms to Context-Aware Forms, you eliminate manual draft preparation, stop duplicate data entry, and finally close the gap between Jira’s "brain" (automation) and its "hands" (collaboration).

That is the difference between sending a link and sending a solution.

4 comments

Ibrahim Khalil
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 12, 2026

This hits on a massive friction point for anyone building automated workflows. Using URL parameters with smart values is a solid way to keep that issue context alive without forcing users into the "double-entry" dance. Phase 4 is the real game-changer—having the form submission actually drive the issue status is exactly how we should be closing these automation loops.

s_gridnevskii
Contributor
February 12, 2026

Ι've been using it for a while for situations when vendors send proforma invoices and we block limits on cash accounts. After goods are received bookkeeper converts pro-forma request into a real invoice request using an URL created by automation in comment. No need to fill data again, just check if everything is correct.

Link looks like this

https://mycompany.atlassian.net/servicedesk/customer/portal/9/create/468?customfield_11904=Vendor_name&customfield_11908=USD&customfield_11905=3120&customfield_11907=Supplies&duedate=2026-12-23&customfield_12605=FIN-6565&customfield_11910=account_id

FIN-6565 is the original proforma request - it eventually gets converted into a link between proforma request and invoice request.

s_gridnevskii
Contributor
February 12, 2026

BTW it would be nice if some kind of AI could convert incoming email with attached picture (or PDF) into a request with all fields filled according to what is on the picture. It will eliminate manual work. Maybe if invoice is within limits it can be paid automatically as well by a web call from automation rule to a payment service.

Olha Yevdokymova_SaaSJet
Atlassian Partner
February 12, 2026

@s_gridnevskii 
Yeah it can also be used like that, but more magic happens when Jira Smart values + Automation come to action and there is no need to even enter the link detalies, but this is more related to the cloud, dont know how this works on DC😌

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events