Dynamic Approvers: Let the Form Pick the Approver

[#1]

I'm starting a series called Tips & Tricks with Smart Forms for Jira — short posts about configuration patterns that aren't obvious from the docs but save a lot of pain once you know them.

First one: approval routing. Specifically this question, which I see constantly:

"How do I automatically assign the right approver based on what someone picked on the form?"

The answers you'll find usually point to IF/ELSE automation rules (one branch per department, maintained forever) or Assets/CMDB. Quick note on Assets before we go further: Assets is a Jira Service Management feature. If you're running JSM, it's available to you. If you're on Jira Software or Jira Work Management without JSM, it isn't — and you don't need it for what I'm about to show anyway.

Smart Forms works across all Jira project types — Software, Business, and Service Management, Jira Product Discovery — and the approach here works in all of them without any JSM dependency.

First: a quick note on Jira's approval field

For approval steps to work in your workflow, you need a User Picker (single user) custom field. Go to Settings → Work Items → Fields → Create field → User Picker (single user), name it Approver or something that makes sense in context, add it to the relevant screens, and wire it to your workflow: open the status where approval should happen, click Add → Approvals, set the Approver source to your new field.

One thing that trips people up: the field's Applicable context must be Global. If you created it scoped to a specific project and it's not showing up in the workflow approval dropdown, that's why. Edit the context to Global and it'll appear.

A note on multiple approvers and groups: Smart Forms currently maps to single User Picker fields. If your workflow needs Group Picker fields or multiple-user assignments, the Jira Automation method (Method 2 below) is the better path — automation handles those field types directly without relying on Smart Forms mapping.

Method 1: Hidden fields + form logic

This is the form-native approach. No automation rule needed for the routing itself.

The idea is straightforward. Smart Forms lets you add fields that are completely invisible to the person filling out the form — hidden elements that still carry values and map to Jira on submission. Combine that with form logic, and you get routing that lives entirely inside the form.

The trick: form logic on fields the submitter never sees

Most people use Smart Forms' conditional logic (the When/Then rules) to show or hide questions. If someone picks "Sick Leave," a doctor's note field appears. Standard use.

What's less known is that form logic also works on fields the submitter never interacts with.

The pattern:

1. Submitter picks a department from a visible dropdown — IT, HR, Finance, Legal
2. The form has one hidden text field per department, each pre-loaded with that department's approver value
3. A form logic rule activates the right hidden field based on the dropdown selection
4. On submission, only the activated field's value writes to Jira

Submitter sees a dropdown. Jira gets a populated Approver field. Nothing else needed.

Setting it up

Step 1 — The visible dropdown

Add a Dropdown element. Label it something a real person would understand: "Which team handles this?" Add your department options — IT, HR, Finance, Legal, whatever applies. This is the only routing question the submitter answers.

Step 2 — One hidden field per department

For each department, add one more dropdown element. You'll hide it and pre-load it with the approver's value.

• Label it for your own reference in the builder: Approver – HR, Approver – IT. Only admins see this.
• Pre-fill this dropdown with the user picker field that you need for approvals
• Set a default response: the approver's Jira username or account ID — the exact value that would populate a custom User Picker field in Jira.
• Hide it: hover over the element, click the eye icon. It becomes a crossed-out eye. Invisible to submitters, fully active in the background.
• Map it to Jira: connect it to your User Picker custom Approver field.

Repeat for each department. In the form builder it looks like this:

[Dropdown – visible]    "Which team handles this?"
                         IT / HR / Finance / Legal

[Text – hidden]         "Approver – IT"
                         Default: john.doe
                         Maps to: Approver (User Picker)

[Text – hidden]         "Approver – HR"
                         Default: sarah.chen
                         Maps to: Approver (User Picker)

[Text – hidden]         "Approver – Finance"
                         Default: alex.kim
                         Maps to: Approver (User Picker)

[Text – hidden]         "Approver – Legal"
                         Default: maya.patel
                         Maps to: Approver (User Picker)

Step 3 — Form logic rules

In Form Logic, add one rule per department:

WHEN: "Which team handles this?" is "HR"
THEN: Show "Approver – HR"

WHEN: "Which team handles this?" is "IT"
THEN: Show "Approver – IT"

WHEN: "Which team handles this?" is "Finance"
THEN: Show "Approver – Finance"

Here's what happens under the hood: in Smart Forms, hidden fields stay invisible regardless of what form logic tells them to do. Even when a rule says "show" a hidden field, it doesn't appear on screen. But the logic rule activates the field — and an activated field submits its default value.

When someone picks "HR," the HR hidden field activates and sarah.chen gets written to the Jira Approver field. The other hidden fields stay inactive and don't submit.

Set Create New Work item to create new work items after the form submissions and add field you wanna map to Jira as well as Approver fields. Map all hidden values to the Approver field, but after submissions thanks to conditional logic only one of approver will be mapped to Jira. 

One more ability

You can use text field for this logic insted of approver dropdown. The default response in a hidden field has to be the approver's Jira account identifier — the username or account ID that the User Picker field accepts. It won't accept a display name like "Sarah Chen." If you're not sure what value to use, open a Jira work item, manually set the Approver field to the person you want, then look at what the field stored — that's the format you need.

Method 2: Field mapping + Jira Automation

This is the right approach when you need Group Picker fields, multiple approvers, or you simply prefer to manage routing logic centrally rather than inside the form.

The setup has two parts: Smart Forms for Jira maps the department selection to a Jira custom field, and Jira Automation reads that field value to set the approver.

Step 1 — Map the dropdown to a custom field

Create a Select List (single choice) custom field in Jira called Requesting Department. Add the same options as your form dropdown.

In Smart Forms for Jira, map the department dropdown element to this custom field. When someone submits the form, their department selection writes directly to Requesting Department on the work item.

Step 2 — Build the automation rule

WHEN: Work item created

IF:   "Requesting Department" = "HR"
THEN: Edit work item → Set Approvers = sarah.chen

ELSE IF: "Requesting Department" = "IT"
THEN: Edit work item → Set Approvers = john.doe

ELSE IF: "Requesting Department" = "Finance"
THEN: Edit work item → Set Approver Groups = finance-approvers

Because the routing happens in automation rather than on the form, you can set any Jira field type here — User Picker, Group Picker, multiple users. The form just passes the department value; the automation rule handles the rest.

Scoping the rule to this form only

One practical tip: if your project has multiple forms or work item types, you don't want this automation firing on everything. Add a hidden field to your Smart Forms form with a fixed default value — something like approval-routing — and map it to the Labels field. Then add a condition to your automation rule:

IF:   Labels contains "approval-routing"
AND:  "Requesting Department" = "HR"
THEN: ...

That label comes from the hidden field on submission, so it only appears on work items created through this form. Your automation stays scoped exactly where you want it.

Which method to use

	Hidden fields + form logic	Field mapping + Automation
Works without Jira Automation	✅	❌
Supports Group Picker	❌	✅
Everything in one place (form builder)	✅	❌
Easy to update when approver changes	Update default value in form	Update automation rule
Works across all Jira project types	✅	✅
No JSM required	✅	✅

For small teams with individual approvers per department: Method 1 keeps everything in the form builder and involves zero automation. For larger teams with group-based approval, rotating approvers, or multi-step workflows: Method 2 gives you more flexibility at the cost of one automation rule to maintain.

A few things to know about hidden fields

Hidden fields are invisible on the form but they do appear in the Smart Forms Responses tab, in exported PDFs and spreadsheets, and in the Jira work item in the mapped field. They don't show up in the read-only submitted form view inside the Jira issue panel — so agents won't see a pile of blank approver fields when they open the ticket.

Why bother vs. just using automation?

The automation approach works:

WHEN: Work item created
IF:   "Department" = "HR"
THEN: Set Approvers = sarah.chen

ELSE IF: "Department" = "IT"
THEN: Set Approvers = john.doe

The problem isn't the logic — it's where the logic lives. When Sarah moves roles, someone needs to find that rule, remember what it does, and update it. Same when you add a new department. Over time, routing logic that started clean becomes a thing that works but nobody can fully explain.

With hidden fields, everything is in the form builder. The person who manages forms can see the routing, update a default value in two clicks, and add a new department in under a minute. There's nothing buried in the automation rule list.

Automation still makes more sense when:

• You have many departments and want approver assignments managed separately from form config
• You're already using Jira groups heavily and rotating membership is how you manage approvers anyway
• You're routing from one form into multiple projects

The form-logic method deserves more attention than it gets. That is why I wrote this up.

What's next in this series

1. Jira Automated actions with forms in Software project
2. Cloning Forms Across Projects
3. How to manage advanced forms and SLA in Jira Software
4. Smart links — open a form with fields already filled in