I'd like the form to be open with the Jira issue details already populated in it.
That's it. That's the entire request. And yet it turns out to be rather complicated.Here's the scenario that we all come up against. A work item is created automatically (from an intake form, an API call, an automation rule running in the background etc).
It's all good looking. It has a summary, a description, a due date, a budget and all the custom fields populated.So far, so good. Then it gets to the human step. The work item goes to Review or Waiting for Approval and at that point someone has to sign off on it; that could be a manager, a stakeholder or a customer.You send them a form.And that's when the friction begins.
The Blank Form Problem
The form opens... blank, even though all the information is already present in the Jira work item.So now:
- The approver retypes the budget.
- The customer retypes the description.
- The manager takes the due date from the email.
It seems utterly unnecessary as it is in fact unnecessary.And if you're the admin, it gets worse:
- You open the work item by hand to populate the form.
- You save it as a draft so that it becomes shareable.
- Your automation can send an email but it can't pass the work item context into the form.
On paper it's all automated. In practice it breaks right before the bit that actually matters.
Why This Happens
Jira Service Management forms work really well within the portal. Jira Automation is very powerful. The problem comes when you try to dynamically link the two, particularly when you're trying to do it for people who don't work in your Jira. You hit a brick wall in that scenario.A form that opens from an external link has no idea whatsoever about the work item. It doesn't inherit anything. It starts from scratch.There's no built-in way to say:"Take what's already in this work item and show it in the form."So the admins go digging through the community threads on URL pre-population, smart values, draft workarounds and all sorts of other clever hacks. What you really want isn't just a form link. You want a form that already knows the work item.Quick terminology clarification: pre-filling the answers (in this article) is different to pre-filling the options in a dropdown with live Jira values.
If you're after the latter then have a look at Dynamic Forms in Jira: Automate form options with live data from Jira fields.
How to Make the Form Arrive Already Knowing the Answers
If your goal is:When you click the form it should be pre-populated with the data from the Jira work item.You can build that flow with Smart Forms for Jira in conjunction with Jira Automation. Since the publication of this article there have been two ways to do it:
How values get in | An automation action attaches the form and copies values from the work item fields you mapped in the form's Settings. | Placeholders in the form, such as {budget}, are filled from parameters your rule adds to the form link. |
|---|
Form elements | Elements mapped to work item fields | Single-line and multi-line text |
Email link | The form URL smart value alone | The form URL smart value + ¶m={{…urlEncode}} |
Best for | The form belongs to an existing work item and you want the simplest rule | Choosing per rule exactly which values travel with the link |
With either method the recipient opens and submits the form without having a Jira account. Here's what that looks like in practice.
Phase 1: Prepping the "Dynamic Receivers"
In the Smart Forms builder you don't just build fields, you build receivers.
- For URL parameters: in each field you want pre-populated, put a placeholder in its Default Response (in curly braces): {summary}, {budget}, {dueDate}. Any name will do, it's case sensitive and must exactly match the URL parameter. Placeholders work in both single line and multi line text fields. More on Default Values: Use Default Responses to guide users in Jira.
- For Attach Smart form with values: open the form's Settings tab and map each element to the work item field it should populate, e.g. Request ← Summary, Budget ← Budget.
- Hide what you don't want edited. A hidden work item key will still be present on the submission so that automation can use it later on to route or link. See How to use hidden fields in Jira forms (and why they matter).
Phase 2: Zero-Touch Attachment
Forget saving drafts. You now have two zero-touch options:
- Auto-attach by work item type. In the form's Settings select 'Add to work item automatically' and then select the projects and work item types. The form is attached at the moment the work item is created and its shareable URL is generated immediately.
- Attach from Jira Automation (new). Smart Forms have two actions available in Jira Automation: Attach Smart Form (which will attach one or more blank forms) and Attach Smart Form with values (which will attach a single form that's already been populated from the work item). These can be used to attach the form at the point in the workflow when you actually need it (e.g. on the transition to Waiting for Approval rather than at creation). In JSM projects the Internal/External toggle will determine whether the agent sees the form in the work item or the customer sees it on the portal. Full walkthrough: NEW Jira Automation for Forms: Attach the right form at the right moment.
Phase 3: The "Magic" Automation Rule
This is where the friction goes away. Set a trigger (e.g. the status changes to 'Waiting for Approval') and add the standard Jira 'Send email' action. The recipients can be the reporter, the assignee, any address or a customer email which is stored in a custom field (e.g. {{issue.customfield_10255}}).
To put the form link in the email body, use this smart value:{{#issue.properties."saasjet.forms.formsSharedUrls"}}{{#if(equals(formName, "Budget approval form"))}}{{url}}{{/}}{{/}}
Just attach the smart form with the values on it, that's all. The values are already on the form.
With URL parameters you append the work item data to the end of the link. That's where you're injecting the Jira data into the form.{{#issue.properties."saasjet.forms.formsSharedUrls"}}{{#if(equals(formName, "Budget approval form"))}}{{url}}{{/}}{{/}}&summary={{issue.summary.urlEncode}}&budget={{issue.customfield_10050}}&dueDate={{issue.dueDate}}
- Use .urlEncode on the text fields so that spaces and other characters don't break the link.
- Parameter names must match the placeholders and the form name is case sensitive.
- Replace customfield_10050 with the ID of your own Budget field. Any system or custom field will do.
More smart value patterns: From Form to Action: Jira Automation with Smart Values from Dynamic Forms and How to Automatically Send Jira Forms to anyone.
When the stakeholder clicks, they don't see a blank page. They see a personalized form that already contains the context. They review it, answer the one or two questions that are actually new, and submit.
Before you roll it out:
- One link, one response. A form shared from a work item accepts a single submission, and the link expires after one month. To collect answers from several people, attach several copies of the form (or add one "with values" action per form).
- Link control. A green icon means the URL is live. Deactivating it blocks access right away. Regenerating it permanently breaks the old link.
- No user pickers on external forms. A user picker field locks the form to "Verified in instance", so people outside your Jira can't open it.
- Keep sensitive data out of URLs. URL parameters can end up in browser history and logs. For anything sensitive, use Attach Smart form with values instead.
Collecting from a website rather than from a work item? The same placeholders work with values your own site's script adds to the link. See How to Build a Public Jira Portal with Request Forms on Your Website.
Phase 4: Update Work Item Fields After Submission
This is the step that teams normally expect the workflow to proceed to, though in many cases it simply doesn't.
With Smart Forms, you can configure the form so that after submission it:
- updates work item fields automatically (Settings → Update existing work item fields)
- transitions the work item to the next status
In practice, this means:
- An approval choice updates an Approval Status field.
- A confirmed date updates the Due Date.
- A revised budget updates a custom field.
- A CSAT rating fills in a Satisfaction Score field.
- A selected asset updates a Jira Assets field: populate a choice element from the Assets field, then map it back.
- An "Approved" response moves the work item to the next workflow step.
You don't any longer need to copy the values from the form into the work item by hand or create a separate automation rule just to sync the response. The form ceases to be a standalone data collection step and becomes part of the workflow. Deeper dives: Update Jira Issue Status after Form Submission and Make Form Completion part of the Jira Workflow.
Bonus: if you connect Smart Forms to Atlassian's Teamwork Graph then responses from open access forms become searchable in Rovo Search and Rovo Chat. You can ask "which budget approvals mention print?" rather than having to go through each response individually. Background: Agent-Ready Intake in Jira: From Forms to Rovo Agents.
Where This Actually Changes Your Workday
Finance Approvals | Approvers see the Budget and Project Scope pre-filled and just hit "Approve." Combine with Dynamic Approvers to route the approval to the right approver based on the answers, and a Calculation field to recompute totals if they adjust line items. |
|---|
CSAT / NPS | The survey already knows the ticket ID and customer name: higher completion rates, zero confusion. In JSM, attach it as External so it appears on the portal. More: Effective Feedback Management in Jira. |
Change Management | Deployment dates and impact scope come from the ticket, and stakeholders just validate. See Jira Change Request Form. |
HR Onboarding | New hires confirm start dates and equipment that are already on the form. See Building HR Self-Service with JSM, Rovo, and Smart Forms. |
Customer follow-ups | When the first form has created the work item, a second pre-filled form collects only the missing details, and the answers land on the same work item. See One form, many hands. |
The Bottom Line
This is not simply about saving a few keystrokes. It's about process integrity. Going from static forms to Context-Aware Forms eliminates the need for manual draft preparation, removes the need for duplicate data entry and finally closes the gap between Jira's "brain" (automation) and its "hands" (collaboration).That's the difference between just sending a link and actually sending a solution.If you're setting this up and get stuck on a smart value or a field mapping, share your scenario in the comments and we'll help you work through it.
