Choosing the right approvers for requests is an important part of effective and smooth workflow management in organizations. The appropriate individuals or teams can review and approve requests, ensuring that they move forward and finish on time.

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 roles, 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 sets 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 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. The initial setup may need technical knowledge, but the efficiency and scalability are worth it.

Using automation rules and APIs to get users in the project role "Approvers" can help organizations have a consistent and efficient approval workflow. This can boost productivity and collaboration among teams, and it can help organizations reach their goals faster and better.