Community Announcements have moved! To stay up to date, please join the new Community Announcements group today. Learn more
×Hello,
We use our Jira to track all the work items that we have to do across multiple projects, and I know we can create look up tables in automations but I don't want to repeat that for every automation we have, and have duplicate data copied. My hope is to create a table somewhere (somewhere in Jira? Confluence?) with columns like:
Project Type | Project Name | Project Lead | Project Sub Lead | Project ID
1 Test_A J Doe J Smith 123
1 Test_B J Smith A Name 456
2 Test_C A Name J Doe 999
And then depending on the value chosen in the Jira issue (ie. Project Name), it goes to this table, and populates fields like project lead and project id on the ticket itself. Is there a way to do that?
Use Case:
In Jira system project, a user creates a work item called Deliverable. They select Test A as their project name. A field called Project Lead will need to be populated so that the developer knows who to contact for any questions.
Instead of this needing to be manually selected by whoever is creating the ticket (not necessarily the project lead), would want Jira to be able to refer to this table, and based on Project Name pull the applicable information.
Thank you!
Welcome to Atlassian Community!
Just to add to @Trudy Claspill answer, if you happen to have JSM then this can be solved by using Assets. You could then use object lookup in the automation to fill out the fields.
Hello @Samantha Concepcion
Welcome to the Atlassian community.
Is there a reason you could not use a Global Rule so that the table is created only once?
Automation Rule tables support only a key and one value, so you would need multiple tables within the rule if you have multiple values to associate to a key (Project name).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi! A Global rule could work, I was thinking a table or something that Jira could read from for a couple of reasons:
- We have about 200 projects and growing so we'd need 4 lookup tables per item we need
- Information that changes would need to be maintained by a Jira admin, the project manager couldn't go into the automation to change the rules (ie. if their secondary person changed)
I'll play around with the global rule to see if I can get it to work for me in the interim while I try to figure out a tabular solution! Thank you for the suggestion!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
A potentially good alternative, as @Mikael Sandberg mentioned, is the Assets functionality available with JSM Premium. Unfortunately the Assets feature is not available in the free or Standard plans. But if you licensed Jira for even a small number of agents that would give you a powerful feature for managing this project related information, which could be referenced through Automation Rules without having to maintain a table in a rule.
In Assets you could create a "Project" type of asset, and add attributes to it for Project Lead, Project Sub Lead, etc. In an Automation rule you could reference the Project of the issue in context, using that information to lookup the Project "asset" to get the other information you need.
You can also set Permissions within Assets to define by groups and by individual users who can manage the data, so managing it does not have to be limited only to Jira Admins.
Other alternatives to consider are third party apps that let you add "attributes" at the project level. I have never used these so I don't know if the information thus added can be accessed through Automation Rules.
Two that I have seen mentioned in other posts (there may be more) are:
Project Properties for Jira Cloud
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.