Jira Automation: Convert Intake Request to Story and Route to Correct Team Space based on Form Field

[arunachalam_angusamy]

I’m looking for guidance on configuring Jira Automation for the following scenario and would appreciate a full automation rule setup (trigger, conditions, branching, and actions).

Scenario:

We have an Intake Request (JSM issue / request type) that goes through an approval workflow. Once the request is approved, we want to automatically create a Story in the appropriate team’s Jira Software space.

Requirements:

1. When an Intake Request is approved, an automation should create a Story.

2. The Story must be created in a specific team’s space based on the value selected in a form field called “Process Impacted”.

3. The automation should route the Story to the correct team project depending on that field value.

4. The automation should run only after the Approver approves the transition.

5. Approvers will be different person in the field value (For Example: Payroll - Person1, Benefits - Person 2). Once approvers approve, I need to create the story in the respective team project / team space. 

Example Mapping:

• If Process Impacted = Payroll → Create Story in PAYROLL project

• If Process Impacted = Benefits → Create Story in BENEFITS project

• If Process Impacted = Recruiting → Create Story in RECRUIT project

Additional Details:

• The intake request uses Forms (JSM Forms).

• The Process Impacted field is a single-select dropdown on the form.

• We want to pass key fields from the intake (summary, description, priority, attachments if possible) to the created Story.

What I’m Looking For:

• Best practice for triggering the automation after approval

• How to read the form field value in automation

• Whether to use If/Else conditions or Branching for project routing

• A complete automation rule example (trigger → conditions → actions)

• Needed a logic to use in JSM Approval. 

Screenshots or step-by-step explanations would be extremely helpful.

[Trudy Claspill]

Hello @arunachalam_angusamy 

Welcome to the Atlassian community.

Have you tried to create this rule or any portion of this rule? I would encourage you to do that.

For instance you could start with a Manually triggered rule that creates an issue in another project.

Then working on creating that issue differently based on a value in a field in the trigger issue. I recommend using If/Else logic for that.

With regard to access data in Form fields there is documentation here that you can review about smart values (used in Automation) to access Forms and fields in Forms:

https://support.atlassian.com/jira-service-management-cloud/docs/access-smart-values-for-forms-and-form-fields/

With regard to triggering the rule based on the item getting approved there is an Approval Completed trigger available out of the box.

https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Approval-completed

Try a few things, using test Spaces or a test instance so that you don't negatively impact your production data. Come back to us with questions.

[arunachalam_angusamy]

Thank you for your thoughts. I applied them. I tried it earlier with one team project and was able to do it successfully. Now I’m trying to apply it to multiple projects, and I got stuck. I think I can use it in an If‑Else branch, and it should work, I believe.

[Trudy Claspill]

Please let us know if you are successful, or if you have more questions on this implementation. Good luck!

[arunachalam_angusamy]

Hello Trudy,

Initially, I was able to retrieve the form ID and the form instance ID for an issue submitted via a form. I tested this successfully in Postman by hardcoding those IDs for a single issue, and the API returned the expected response.

However, I noticed that if an agent edits and saves the form, Jira creates and attaches a second form instance to the same issue, resulting in two different instance IDs.

This is where I am currently stuck. Now I am struggling to understand how to dynamically retrieve the correct instance ID and pass it into my automation rule so that I don't have to hard code and tried to look at the API documentation and it is not much helpful.  

[arunachalam_angusamy]

[arunachalam_angusamy]

I tried this to log an action 

=== Forms Attached to {{issue.key}} === {{#issue.forms}} Form Name: {{name}} Form ID: {{id}} Instance ID: {{instanceId}} State: {{state}} --- Field Values --- {{#fields}} {{name}}: {{value}} {{/fields}} ==================== {{/issue.forms}}

but is generating the empty values 

=== Forms Attached to ISSUE-12 === Form Name: Form ID: Instance ID: State: --- Field Values --- ====================

https://api.atlassian.com/jira/forms/cloud/MyCloudID/issue/{{issue.key.urlEncode}}/form/{{issue.forms.first.instanceId.urlEncode}}

--- Get this error message 

Unable to publish the web request - received HTTP status response:
401
Error found in the HTTP body response:
{"code":401,"message":"Unauthorized"}

Definitely, it is not with Token. Same token is used in other automation and it is working as expected

[Trudy Claspill]

Hello @arunachalam_angusamy 

There are three things I want to address from your previous responses:

• Part 1 - getting a second copy of the form when the agent edits it
• Part 2 - attempting to iterate over the form's field list dynamically
• Part 3 - your failed api call

----- Part 1 - a second copy of the form when the agent edits it

You said when the agent "edits" the form and saves it another copy of the form is attached. I am not having the same experience. What I see is that if I (as an agent) edits a Submitted form and clicks Submit on that form, then there is no additional copy of the form added to the item. What is the status of the form that your agents are editing?

----- Part 2 - attempting to iterate over the form's field list dynamically

Regarding your attempt to list the fields included in the form, I don't think that is possible. I have not found any information that indicates "fields" is a valid property for a Form. All the examples instead show that the fields are referenced directly by their key (which you set within the form builder).

From the documentation:

Retrieve form fields with smart values
To access a specific smart value of a form field, you’ll need to know both the field type and the field key which acts as the unique identifier of a field in a form.

----- Part 3 - your failed API call

Regarding the failure of the API call, where are you executing that call? Are you executing it from within an Automation rule, or from Postman, or a terminal?

How did you provide your authentication credentials?

When providing your token did you provide a base64 encoded token?

Did you generate a scoped token or non-scoped token?

Another thing I have found is that the hexidecimal value from {{issue.forms}} is not the ID for the individual form attached to the issue. Instead it is the ID of the Template the form used. To get the ID of the attached form you need to use the Get Form Index API endpoint.

You can then use the obtained ID in the Get Form API call. Prior to discovering that I was using the ID from {{issue.forms}} and was getting the same Unauthorized error as you.

So far I have used only hard-coded values in my rule to test this out. I have not yet tried getting values and then providing them via smart values to the next step.

In my test case I had two forms, from two different form templates, attached to my work item.

And I'm still working on referencing the fields for a specific attached form in this scenario where there is more than one attached form.

[arunachalam_angusamy]

I used basic authentication with non-scoped token and was able to get it successfully.

[Trudy Claspill]

That's great!

Do you have additional questions?

[Bill Sheboy]

Hi @arunachalam_angusamy 

Adding to Trudy's suggestions...

As a reminder, this is the Atlassian Community.  It is a place for people to collaborate and learn from one another.  It is not free labor source to build automation rules upon demand.  Community members recommend first trying to create a rule to focus what help is needed for your scenario.  When you encounter rule challenges, posting images of your rule and audit log, and explaining the challenges, help the community offer better suggestions.

When you regularly need additional help creating rules, I recommend discussing this with your Jira Product Admins to get their support and to learn about free training from Atlassian on automation rules:

https://community.atlassian.com/learning/catalog?search=automation

Kind regards,
Bill

[arunachalam_angusamy]

Thank you for the reminder and the guidance. I appreciate the perspective. That’s fair feedback.

To clarify my intent: I am not looking for someone to build the automation for me. My intention is to understand if others have encountered a similar situation before, learn what approaches worked well for them, and compare those patterns with my own implementation so I can adopt best practices.

I will share the automation that was already I explored with it without the approval. 

Appreciate the suggestion about Jira Product Admins and Atlassian training as well. I will look into those resources too.

Thanks again for keeping the community collaborative and focused.

[Bill Sheboy]

Thanks, and I look forward to seeing your rule / audit log to help with anything not working as you expected.

[arunachalam_angusamy]

Hello @Bill Sheboy 

Added the initial rule and logs and Postman response as well. I would appreciate if you have any thoughts.