Dynamically Defining Approver Field The Jira Automation Way

[Kiet Ngo]

In my previous blog, I discussed the topic of "Pragmatic Jira Automation: A Governance Approach". Today, I will show you how to define an approver field using Jira Automation dynamically.

Defining request approvers is a crucial aspect of efficient and streamlined workflow management in organizations. Choosing the right approvers ensures that requests are reviewed and approved by the appropriate individuals or teams, facilitating smooth progress and timely completion.

In this article, we explore two commonly used approaches: letting customers choose approvers and setting default approvers. Additionally, we introduce our own preferred method, which leverages project roles, automation, and APIs to configure approvers. By understanding the benefits and limitations of each approach, organizations can make informed decisions to enhance their approval processes.

Loose: Letting customers choose approvers

This approach allows customers to select the approvers for their requests. When submitting a request, customers can specify who they believe should approve their request. See this article for the how.

                                               Let the customers choose the approver(s)

Pros

• Flexibility: Customers have control over the approval process and can choose the appropriate approvers based on their requirements and preferences.
• Customization: Allows for specific approvers to be selected for different types of requests, enabling a more tailored and dynamic approval workflow.
• Improved communication: Customers can directly involve the relevant stakeholders in the approval process, promoting collaboration and transparency.

Cons

• Potential delays: If customers are not familiar with the appropriate approvers or if there are too many choices, the selection process may introduce delays as customers try to make decisions.
• Inconsistent choices: Different customers may choose different approvers for similar requests, leading to inconsistency in the approval process.
• Risk of inappropriate choices: Customers may lack knowledge about the appropriate approvers, potentially selecting individuals who are not actually qualified or relevant to the request.

Tight: Defaulting the Approvers

Alternatively, you can set default approvers in advance for certain request types or categories. With this approach, you define a predefined set of approvers for specific types of requests. Whenever a customer submits a request falling under a particular category, the default approvers are automatically assigned. See this article for the how.

                   Presetting the approvers and hiding the Approver(s) field from the portal

Pros

• Streamlined process: By setting default approvers, the approval workflow can be standardized, saving time and effort for both customers and service teams.
• Consistency: With predefined approvers, there is a consistent and predictable approach to approvals, ensuring that the appropriate individuals or groups are involved.
• Reduced decision-making burden: Customers don't need to spend time selecting approvers, as the defaults are already established.

Cons

• Limited customization: The default approvers may not always align with specific customer requirements, resulting in less flexibility for tailoring the approval process.
• Lack of transparency: Customers may not be aware of who the default approvers are, which could lead to questions or concerns about the approval process.
• Difficulty accommodating exceptions: If a request requires a deviation from the default approvers, additional steps may be needed to override the predefined settings.

Dynamically: Setting Approvers Using Project Roles, Automation, and APIs

At AgileOps, we actually configure approvers the third way, using project role, automation, and APIs.

With this solution, the final result will be:

• The customer raises a request
• Jira automatically pulls a pre-defined set of users from the "Approvers" project role and set them as the approvers of the request
• (Optional) The request’s approvers are notified on the company communication platform (e.g. Slack) that there is a request pending their approval
• Whenever the approvers are changed (there is a new approver or an existing approver leaves the company), the project admin just needs to edit users in the "Approvers" project role

Here is how it’s set up:

Step 1: Create the “Approvers” project role

1. Go to System > Project roles (under the Security section)
2. Click Add Project Role
3. In the Name field, enter Approvers
4. In the Description field, enter a brief description of the role
5. Click Add Project Role

Step 2: Add users to the “Approvers” project role

1. Go to your project settings and open the People section
2. Click on Add people
3. Enter the usernames of the users you want to add as approvers
4. Choose the role Approvers
5. Click on Add

Step 3: Retrieve the approvers when a new ticket is raised

1. Go to your project settings and open the Automation section
2. Click on Create rule
3. Set the trigger to be Issue created
4. Set an action to be Send web request
5. Configure the web request to retrieve users currently having the project role “Approvers” through Jira API (see here for detailed documentation)

Step 4: Format the web request response

1. Add an action to Create variable.
2. Set a Variable name (in this case is allAccounts)
3. Define the smart value to format the web request response: {{webResponse.body.actors.actorUser.asJsonObjectArray("accountId")}}

Step 5: Edit Approvers field of the ticket

1. Add an action to Edit issue
2. Edit the field Approvers (custom field with the ID 10003) with the smart value allAccounts

Step 6: Notify Approver through Slack

1. Add an action to Send Slack message
2. Configure the message to notify the approver(s) that there is a request pending their approval using the syntax {{#issue.Approvers}}<@{{properties.metadata.slack_id}}>{{^last}},{{/}}{{/}}
3. Save the rule and turn it on

Step 7: Action - Approver for ticket is set and notified

Now, when a new ticket is created, the Approvers field is automatically populated with users with the Approvers project role. They will also receive a notification on Slack.

The biggest cons of this approach is, you guessed it, the complexity of setup: It requires configuring automation rules and custom scripting, which may require technical expertise and effort. But the advantages are well worth it.

Here’s how it's better than both previous approaches:

• Consistency and scalability: Using project roles ensures that the appropriate individuals or teams are consistently assigned as approvers for requests across the project. It also allows for easy scaling and management of approvers as project roles can be easily modified.
• Streamlined process: With automation and project roles, the approval assignment happens automatically, saving time and effort for both customers and service teams.
• Reduced manual errors: By automating the assignment of approvers based on predefined project roles, the likelihood of manual errors or oversight is reduced.

The three approaches to defining request approvers presented in this article offer a range of benefits and limitations. Letting customers choose approvers provides flexibility, but it can lead to inconsistent and delayed approvals. Setting default approvers can streamline the approval process, but it can be limiting and difficult to accommodate exceptions.

Configuring approvers based on project roles, automation, and APIs offers a balanced approach that combines the benefits of flexibility, consistency, and reduced manual errors. While the initial setup may require some technical knowledge, the benefits in terms of efficiency and scalability outweigh the complexity.

By leveraging automation rules and APIs to retrieve users in the project role "Approvers," organizations can achieve a consistent and efficient approval workflow. This can promote productivity and collaboration across teams, and it can help organizations to achieve their goals more quickly and effectively.

The final blog in the series "Pragmatic Jira Automation: Atlassian's 3 Ways of Using Jira and Confluence Together, We Unveil the 4th Way" will be published soon. In the meantime, don't miss the previous two blogs that I shared:

• Pragmatic Jira Automation: A Governance Approach
• Pragmatic Jira Automation: Atlassian's 3 Ways of Using Jira and Confluence Together, We Unveil the 4th Way
• Pragmatic Jira Automation: Achieving Flexibility in JSM Approval Workflow

Follow me and stay tuned for the upcoming articles on this topic:

• Pragmatic Jira Automation: Jira Governance Loop - Using Jira to Manage Jira
• Pragmatic Jira Automation: Document Generator with Jira, Automation, Confluence, and K15t Scroll PDF Exporter
• Pragmatic Jira Automation: How Did We Use Jira as a full-pledge CRM system

[Rick Westbrock]

Great, thanks very much for that link. That Python script is for Jira Server but I'm sure it won't take much work to tweak it for Cloud.

[Daniel Eads]

Yep that's more or less exactly what needs to be done right now. We've got a script you can use here: Mention someone directly in Slack via Jira Automation (Atlassian Community Article) 

[Rick Westbrock]

How does the rule know the Slack ID of the approver? We have an automation rule which looks up approvers from an Assets object type (instead of the project roles) and want to enhance it with Slack notifications for approval required but I haven't figured out how to get the Slack ID of each approver yet. I imagine we would have to loop the list of approvers and make an API call to Slack using the approver's e-mail to get their Slack ID.