You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
One of the coolest tools integrated with Jira Cloud is the Jira Automation. More and more users create all kinds of automation rules, but most do not realize how powerful and functional these rules can be.
In this article, I will introduce you to some features you may not be aware of.
Let's automate one of the common Jira administrator tasks - Project creation.
Let's imagine that we have a Jira site with some projects and we need to maintain some level of standardization across all of them. We have two project templates that are used to create most of the new projects on our site. In this example, I created separate templates for Software development projects and Internal business projects.
By template, I mean a common, shared schemes configuration setup on a project such as a workflow scheme, issue type screen scheme, permission scheme, and so on.
So far, if we wanted to create a new project, we need to ask the Jira administrator, who will use the shared configuration option, to create the project for us. We will fully automate this process using the solution based on Jira automation rules.
Let's create a new administrative project: “Automatic Jira Support”. I used Jira Service Management, but the same functionality can be achieved on any flavor of Jira Cloud. In the project, create a request type "Request for new Jira project". I placed only 3, all of them required, fields on the create request form:
We use the following workflow:
After creating a new ticket on the portal, the first automation will be launched. Automation will check if the name of the project given by the user is not already in use. If a project of that name already exists, it will reject the ticket with the appropriate comment. Otherwise, the user who is the template's owner will be filled in the Approvers field (each template has its owner responsible for the approval of every template-related user request), and then will transfer the ticket for approval. Approval is implemented using functionality built into Jira Service Management, as a result of which the request will transition to one status: Rejected (in case of rejection) or In progress (in case of acceptance). Jira Service Management approval is configured in Workflow and requires all users in the Approvers field to approve requests. After the ticket is approved, the second automation will launch, generating a new project key and making sure it's available for use. Then it will create a project using the configuration of schemes associated with the selected Template and data entered by the user during request creation, such as name or project lead. If the project creation is successful, the request will transition to the Done status with an appropriate comment added. Otherwise, the ticket will change status to Manual support, it will be assigned to the available Jira administrator with comments intended to help the administrator to solve the problem and create the project manually.
This action is used to communicate between systems to retrieve information or make some changes. In our case, we communicate between Jira automation and Jira itself. You can find Jira Cloud REST API documentation here: Jira Cloud REST API
echo -n "email@example.com:NCduZ9PpqQhOKylIMx4b6152" | base64
After obtaining approval, the issue changes status to In Progress, and the second Jira automation rule is launched. I've set up two automation here (one for each Template). They are almost identical - they differ mainly in the configuration of the Web request body. I will discuss the configuration of the rule using the example automation configured for the Internal business project template.
As a result of this setup, the process of creating a project is very convenient and much shorter:
No human errors, no waiting for the administrator's availability, keeping standardization among projects. Fast, easy, and fun!
This setup can be extended by automatically creating also components, versions, boards, granting project permissions to selected users, etc.
The project can also include other administrative requests, such as creating filters, listing project permissions, or creating spaces in Confluence. The sky is the limit!
If you have any questions about this setup, let me know in the comments.
Piotr Zadrożny _Eyzee_
Atlassian Consultant & Developer
65 accepted answers