Currently we are fetching information of projects details and doing the manual project creation process
idea is to create a project automatically when one of the operation team entered the details in the ticket and submit the request once verified by one transition click need to create a project with custom template.
This could be done in automation trigger the floe, by the transition, add conditions in the rule if needed.
Then add a web request action and use this API endpoint;
Building on Marc and James — the shape they describe is right (trigger on the approval transition → Send web request → project-template endpoint). Four things that tend to bite once you actually build it:
1. Send web request doesn't authenticate as your rule actor. This surprises people. Calling your own site's REST API from Automation still needs an explicit Authorization: Basic <base64 of email:api-token> header — the actor setting governs what the rule does inside Jira, not what your outbound HTTP call is allowed to do. And Automation has no secrets store, so that credential lives in the rule config, visible to anyone who can edit rules. Lock down who can edit that rule accordingly.
2. That credential needs Administer Jira. Creating a project is a global permission, not a project one. So whatever account backs the token is effectively a site admin, and every project your ops team requests gets created by it. Worth deciding deliberately rather than discovering it at go-live — a dedicated service account (not a person's, so it survives them leaving) is the usual answer.
3. Validate the project key before you POST. A key that's malformed or already taken is the most common 400 here, and Automation won't recover gracefully. Add a GET /rest/api/3/project/{key} first — a 404 means the key is free; anything else means stop and comment back on the request instead of firing the create. If ops types the key by hand, that check is doing a lot of work for you.
4. Check what "custom template" means for you. The project-template endpoint creates from a template definition — it isn't "clone project ABC". If what you actually want is "same workflows, screens and fields as our standard project", that's a different job: for company-managed projects, schemes are shared objects, so you create the project and then point it at the existing schemes and the configuration comes along. For team-managed, config is per-project, and you'd be looking at a Marketplace configuration-manager tool. Worth settling this before you write the rule, because it changes the whole approach.
One last thing: creation is asynchronous, so the POST returns a task, not a finished project. Poll /rest/api/3/task/{taskId} before doing anything downstream, then write the resulting project key and URL back as a comment on the original request and transition it to Done — or to a failed status with the error body if it didn't work. Your ops team will thank you the first time something goes wrong.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hola rajeswari,
Yes, this can be automated natively in Jira Cloud, and @Marc -Devoteam-’s suggestion to use Automation with a REST API call is the right direction. Your request already has a natural approval point: the project is created only after the operations team enters the details, and someone verifies them through a transition.
I’d build the Automation around that transition rather than around issue creation. For example, when the request moves to an Approved or Create Project status, the rule can validate that the required fields are populated, then use Send web request to call Jira’s project-template REST endpoint. Atlassian documents that Automation can call Jira REST APIs through Send web request here.
One important detail is the “custom template” requirement. Atlassian now has a project-template API that can create a project from a supplied template definition, including project details and configuration capabilities. The operation is asynchronous, so a successful POST starts the creation task rather than necessarily returning a completed project immediately. Your Automation should account for that if you need to update the original request only after project creation has actually finished.
I’d also store the requested project name, key, lead, template choice, and any other required settings in dedicated fields rather than parsing them from the description. That makes validation and mapping into the REST request much more reliable.
Before building the full rule, I’d test it using a single approved template and a restricted automation actor with only the permissions needed to create projects. Once that works, you can add the template selection and other optional configuration.
The current REST documentation for Jira Cloud project templates is available here.
Thanks,
James
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.