Approval Path for Jira vs Herzum Approval

For people running or being a part of a project, especially a bigger one, it’s obvious that each project is a multi-step process. Each step often requires approval (or various approvals) before proceeding to the next one. For example, when an advertising agency is preparing a campaign for a customer before graphic designers can create visualizations, concepts must be proposed, selected, and approved by the creative team, project manager, and client. But how to manage so many approvals?

Well, luckily for us, there are many Jira apps dedicated to this problem. Today, we are going to compare two of the most popular ones: Herzum Approval and our own app - Approval Path for Jira.

Let’s take a look at how both apps work.

Approval Path for Jira is an add-on that allows users to manage the issue approval process that works on every project type (not only on JSM projects). It enables the creation of an approval definition on a global or project level. Each definition consists of the following types of steps:

• User step → choose a single user,

• Group step → choose a group and voting criteria (number of votes required to pass/reject),

• Email step → add users outside your Jira,

• Issue Field - User → choose a user from the issue field (i.e., assignee, reporter)

• Issue Field - Group → choose a group from the issue field,

• Issue field - Email → specify dynamic external user steps (from issue field),

• Automation/Webhook step → create automation or connect with other applications.

A new, additional automation step is soon to be developed.

For every step, you can choose three action types: approval (approve or reject), consent (consent or reject), or notification (user/group members will be notified about current progress). By default, steps are run sequentially, but you can create a parallel group to put some (or all) steps at the same time. Also, each step can be given with a conditional rule (pre-defined) - the whole definition can have a condition set up as well. The definition can be constructed with an infinite number of steps and parallel groups.
Every definition can be assigned to a specified project or available globally. Also, automatic email reminders can be set with a customizable interval. An unlimited number of definitions can be created.

Prepared definitions serve as a template for approval. The panel with the approval path macro content can be in three different sections on the issue page: in the issue content, activity tab, or details tab. Every definition can be run multiple times and can be adjusted - an expiration date and automatic reminder interval can be set (or disabled). Many approvals can be created simultaneously for a single issue. Reports of every action are recorded in the history/comment tab. Additionally, there is a global/project list of approvals and activities available. The app enables filtering them by selected values.

Approvals can be delegated. Delegations can be assigned to a particular project or globally. Delegators (Global admins can select any user, while regular users can delegate only themselves) select delegatee and, optionally, a group (or groups) to grant the delegatee the right to act on group steps. Delegations can be set up for a specific time range or until changed.

What’s worth mentioning is that the app supports the Jira Permission Scheme and provides API. It has the “Cloud fortified” badge and is a part of the Security Bug Bounty Program, which means that external testers verify the app’s security and reliability.

Herzum Approval (is an app with a similar purpose to Approval Path for Jira, but a bit different approach. Approval steps, called here “approvals” have to be pre-defined by the app’s user. Each step can be single- or multiple-property type filled by various users, groups, or roles (issue fields). Based on those steps, a definition, called “mapping” can be created, but with a maximum of 6 steps. Also, every mapping can be assigned to only one project (and it seems to be unavailable for certain project types, i.e., Project Management projects). Mappings require setting issue transition (it can be disabled in the global settings).

Steps can be run sequentially or simultaneously and can have conditional rules. Approvals can be approved, rejected, or abstained (if the last two options are enabled in the app’s settings). Those actions can be undone. If the “lock” option is enabled, you can block actions on approvals after a specified time (days and hours). A minimum number of votes can be set to approve or reject an issue (as a[percentage or fixed number), with an option to set optional approvals - they are being taken into account only if someone voted.

Approval requests can be manually sent to approvers and they can react via email. Delegations work the same way as in the Approval Path for Jira but can be set for particular issues as well. Approval reports are available in the comments/history tab, but can also be exported to PDF/CSV files. Lists of activities/approvals require custom JQL functions for filtering. The app provides API, but the Jira permission Schemes are not being supported.

But the biggest difference is app performance. Based on users’ reviews and some internal tests, in our app, every action happens immediately, it works without major issues, and we have highly responsive support. The Herzum app seems to work slower (many actions are buffering for a while - which is a nice feature if you want a few seconds breaks ) and there are many problems reported. But don’t trust us, take a look at the reviews!

To sum things up, we have listed the features of both applications in the table below:

Still not sure which app to choose? Don’t hesitate to test them out (free trial available for both)! And if you have questions about our apps, feel free to contact us or to schedule a demo!