NEW Jira Automation for Forms: Attach the Right Form at the right moment automatically

[#1]

Here I am going to describe New Jira Automated actions to add the right form on the right workflow moment that support Jira Software or JSM projects.

Jira Automation handles the mechanical parts well — assigning tickets, updating fields, sending notifications, moving statuses. For a lot of workflows, that's enough. But eventually most of them hit a moment where a system action isn't what you need. You need a person to answer specific questions in a structured way, not in a comment thread, not in a Slack message that gets buried, not in a follow-up email nobody links back to the ticket. This is where structured intake in Jira helps you automate Jira forms without losing context.

Sometimes you need a form — ideally a dynamic form in Jira.

The new Smart Forms action for Jira Automation covers this. In practice, teams attach one or multiple forms on any trigger using a Jira form automation action, so the right questionnaire appears exactly when it's needed. You can now attach one or multiple Smart Forms to a Jira work item — blank, or pre-filled with values pulled from the issue itself.

Why the gap exists

Jira can move work forward, but it cannot always make people explain what happened.

The escalation reason is in a comment from Tuesday. The QA tester opened a Slack thread asking for environment details the developer already knows but never wrote down anywhere. The onboarding work item exists, but IT is waiting on HR, HR is waiting on the manager, and nobody's attached anything to the ticket. The change request reached approval stage, and the approver is scrolling through issue history trying to piece together what they're actually deciding on.

Automation fires at all of these moments. It just can't collect the answer.

What the action does

You add a step to an existing automation rule. When the trigger appears — status change, priority update, field value, label, SLA event, issue creation, approval stage — the form attaches to the work item. One form or several, depending on what the workflow needs.

Using Jira Automation smart values, the form can arrive pre-filled with values from the issue:

{{issue.key}}, {{issue.summary}}, {{issue.reporter.displayName}}, {{issue.assignee.displayName}}, {{issue.priority.name}}, {{issue.components.name}}, {{issue.customfield_XXXXX}}

For parent-child workflows, you can also pull from related items:

{{issue.parent.key}}, {{issue.parent.summary}}, {{issue.parent.customfield_XXXXX}}

These Jira smart values in forms mean the person filling out the form doesn't start from scratch. The context is already there.

How this is different from form intake

Forms have mostly been the front door. Customer submits something, a Jira issue gets created, work starts. That model still works.

The problem is everything that happens after that. A ticket escalates. AA change request needs approval. A manager needs to sign off on something before a new hire's first day. None of these are intake moments — the issue already exists — but they all need structured information that isn't in the ticket yet.

Auto-attach by project and issue type can't handle this cleanly. It puts the form on every matching ticket from creation, regardless of where in the lifecycle the ticket actually is. The automation action is for a different situation: the form appears because something happened, not because the issue type matched. With Jira Automation forms, you attach forms conditionally at exactly the right time.

Where this helps

Support escalation

Ticket priority hits Highest. An escalation form attaches — pre-filled with issue key, summary, reporter, assignee, priority, affected component. The agent fills in what Jira doesn't already know: customer impact, workaround tried, why the escalation was called. That ends up on the ticket, structured, instead of in a comment nobody will find when the incident review happens, and not scattered across ad‑hoc Jira follow-up forms.

QA handoff

Ticket moves to Ready for QA. A Jira QA checklist attaches — summary, fix version, component, developer, linked epic already populated.

Onboarding

New hire ticket is created. One rule attaches the HR form, IT equipment form, security access form, and manager checklist — each for a different team, all tracked on the same work item. If the parent issue carries the employee name, start date, department, and location, those values pre-fill across the relevant forms. Nobody copies them across manually, which means nobody copies them wrong.

Approvals

Change request transitions to Waiting for Approval. With Jira approval form automation, a form attaches — requester, department, amount, implementation date, affected service already populated. The approver sees a structured form instead of scrolling backward through the issue to figure out what they're approving. The decision gets recorded somewhere findable.

Post-resolution feedback

Ticket moves to Done. A CSAT form attaches, already linked to the ticket key, customer, assignee, and product area.

Auto-attach versus the automation action

Smart Forms has also auto-attach feature that allows form to be attached when work item created for checklists, task template, replacing issue creation screens and more.

Auto-attach still makes sense for stable, predictable cases: every Bug gets a Bug Report Form, every Incident gets an Incident Checklist. Set it at the form level.

The automation action is for conditional cases — when the form should appear only after something specific happens. You don't want an escalation form on every support ticket from creation. You want it when a ticket actually escalates. The distinction matters because attaching the wrong form at the wrong time creates more noise than no form at all. In other words, you're creating dynamic forms in Jira that respond to workflow events.

On prefilling

When someone manually copies the issue key, ticket summary, customer name, assignee, and affected component from a ticket they're currently looking at into a form, mistakes happen. If Jira already has the data, the form can carry it — prefill Jira forms with smart values so the context stays consistent.

For parent-child workflows this matters more than it might seem. If an Epic carries a cost center, customer tier, or work code, forms on child tasks can inherit those values automatically across an entire hierarchy of subtasks. No transcription, no inconsistency across a stack of twenty onboarding subtasks.

FAQ

What does the Smart Forms action for Jira Automation do?

It attaches one or multiple Smart Forms to a work item when an automation rule runs — blank, or pre-filled with Jira Automation smart values from the issue. These Jira smart values in forms reduce manual typing and improve accuracy.

Can I pre-fill Jira forms with smart values?

Yes. You can prefill Jira forms with smart values. Issue key, summary, reporter, assignee, priority, project, component, custom fields, and parent issue values can all be passed into form fields at attachment time.

When should I use auto-attach instead of the automation action?

Auto-attach when the form should always appear on a specific project and issue type. Automation action when it should appear only after a workflow event — a status change, escalation, approval stage, SLA breach, or field update.

Does this replace Jira Automation?

No. Jira Automation still controls the trigger and workflow logic. Smart Forms handles what gets asked and collected at that point in the process, helping you automate Jira forms at the right time.

TL;DR: New Jira automated Actions for Smart Forms arrived and allows you to add blank or pre-filled form to the issues of your choice.