Salto for
Jira
Articles
SHARE
Alex Ortiz
January 4, 2024
10
min read
Atlassian recently implemented changes to their billing approach for customers using automation rules in all of their Cloud-based Atlassian products. The following tips are intended to assist you in helping you minimize the impact of these billing and usage changes.
When your Atlassian product reaches the monthly limit, your automation rules will stop running until your next billing cycle starts. This could have serious consequences if your team relies heavily on automation rules.
First, you must understand that every project configuration now contributes to your automation rule usage. While only global and multi-project automation rules were considered when calculating your usage previously, in the new model, any successful execution of an automation rule, whether for a single project, multiple projects, or a global project, will now count toward your usage.
The number of automation rules you and your company can run monthly depends on your Jira product type and Cloud subscription level, whether you're a free, standard, premium, or enterprise customer.
What steps can you take to protect yourself in light of this significant change? My primary recommendation is to start by examining your automation rules for duplicates. Since, by default, any project administrator within your Jira instance can create automation rules, it is quite likely that multiple rules throughout your instance are identical or very similar. Once you identify a duplicate rule, remove it, or if you want to retain the rule, turn it off.
A significant new change regarding how automation rules are now billed is that usage is based on any successful automation rule that executes. If an automation rule runs and completes, regardless of the scope of the automation rule (single, multiple, global), it will now count towards your monthly usage limits. Therefore, a valuable tip is to make it harder for rules to execute successfully.
Suppose your automation rule consists of a trigger and possibly an 'if' condition, followed by an action. In that case, the likelihood of that rule successfully executing and affecting your usage count will be notably high. When you multiply this by the total number of automation rules in your instance, you may find yourself reaching your monthly usage limits quickly.
To mitigate this, it is advisable to make it more challenging for your automation rules to execute successfully. I'm not suggesting that you should break your automation rules; instead, consider adding conditions to your rules. This way, your automation rules will only run under specific circumstances or criteria, ensuring they execute successfully under the right conditions.
Another significant change with automation rule billing is that each Atlassian Cloud product, whether Jira Product Discovery, Jira Work Management, Jira Service Management, Confluence, or Jira Software, now has its own usage limits.
You should ensure that Jira automation rules only run in the specific project for the particular Cloud product for which you have the right subscription.
For example, if you have an automation rule that updates the due date of an issue, you want to ensure that you have a different automation rule running for Jira Software and another one for Jira Service Management because they will be billed differently. There was one comprehensive usage meter in the past, but now usage will be product-specific. Therefore, you should update your automation rules to ensure they run on product-specific projects.
Review all your automation rules and identify any that do not provide specific value. Carefully assess each rule, discuss it with the automation rule owner, and determine if it genuinely adds value.
It is crucial to understand that the days of having single project rules for free are behind us. Check all rules from owners that may not be with your company anymore. Since rules do not have an expiration date, it is possible to be running rules that are not necessary anymore. Keep in mind that every successful rule execution will count against your monthly usage limits, so take the time to double-check the need/validity of each and every rule.
Since this change is inevitable, one of the steps you can take to minimize the impact on your team is to communicate these new changes effectively to all your ORG Admins, SITE Admins, and, most importantly, your project administrators.
Another measure you can implement is restricting the number of administrators at the site, organization, and, most importantly, at the project level. It is crucial as anyone with administrative access can create rules, which means they can potentially increase your expenses with Atlassian.
It is essential to ensure that every person who can create rules comprehends the impact of each automation rule they generate. This will help prevent reaching your usage limits quickly. So, for your own benefit, make a conscious effort to over-communicate these changes and ensure that everyone in your organization with automation rule-making privileges understands the consequences of their actions. Also, don’t forget to mention that you will review and clean up all the rules that do not add value.
Atlassian has also introduced a new feature that allows Jira administrators to control who can create automation rules. Go to the Global Automation setting within Jira and click on the ellipses next to “Create rule”. Select Global Configuration.
Here, you can configure if project administrators can create rules, or you can limit rule creation to a specific group.
Finally, analyze the cost of upgrading to Jira Premium or Enterprise if your company heavily relies on Automation Rules and frequently exceeds the monthly limits. Atlassian gives you a view of every Atlassian cloud product and how many rules have been executed within your current billing period. Conveniently, Atlassian has an upgrade button if you find yourself reaching your usage limits.
It is unfortunate that Atlassian is implementing these changes, and I am confident that these changes will affect nearly every Atlassian customer.
Hopefully, these tips will provide you with some guidance on how to better prepare yourself for the sudden change in Atlassian’s billing and usage structure.
Salto for
Jira
Jira
SHARE
Alex Ortiz
January 4, 2024
10
min read
Atlassian recently implemented changes to their billing approach for customers using automation rules in all of their Cloud-based Atlassian products. The following tips are intended to assist you in helping you minimize the impact of these billing and usage changes.
When your Atlassian product reaches the monthly limit, your automation rules will stop running until your next billing cycle starts. This could have serious consequences if your team relies heavily on automation rules.
First, you must understand that every project configuration now contributes to your automation rule usage. While only global and multi-project automation rules were considered when calculating your usage previously, in the new model, any successful execution of an automation rule, whether for a single project, multiple projects, or a global project, will now count toward your usage.
The number of automation rules you and your company can run monthly depends on your Jira product type and Cloud subscription level, whether you're a free, standard, premium, or enterprise customer.
What steps can you take to protect yourself in light of this significant change? My primary recommendation is to start by examining your automation rules for duplicates. Since, by default, any project administrator within your Jira instance can create automation rules, it is quite likely that multiple rules throughout your instance are identical or very similar. Once you identify a duplicate rule, remove it, or if you want to retain the rule, turn it off.
A significant new change regarding how automation rules are now billed is that usage is based on any successful automation rule that executes. If an automation rule runs and completes, regardless of the scope of the automation rule (single, multiple, global), it will now count towards your monthly usage limits. Therefore, a valuable tip is to make it harder for rules to execute successfully.
Suppose your automation rule consists of a trigger and possibly an 'if' condition, followed by an action. In that case, the likelihood of that rule successfully executing and affecting your usage count will be notably high. When you multiply this by the total number of automation rules in your instance, you may find yourself reaching your monthly usage limits quickly.
To mitigate this, it is advisable to make it more challenging for your automation rules to execute successfully. I'm not suggesting that you should break your automation rules; instead, consider adding conditions to your rules. This way, your automation rules will only run under specific circumstances or criteria, ensuring they execute successfully under the right conditions.
Another significant change with automation rule billing is that each Atlassian Cloud product, whether Jira Product Discovery, Jira Work Management, Jira Service Management, Confluence, or Jira Software, now has its own usage limits.
You should ensure that Jira automation rules only run in the specific project for the particular Cloud product for which you have the right subscription.
For example, if you have an automation rule that updates the due date of an issue, you want to ensure that you have a different automation rule running for Jira Software and another one for Jira Service Management because they will be billed differently. There was one comprehensive usage meter in the past, but now usage will be product-specific. Therefore, you should update your automation rules to ensure they run on product-specific projects.
Review all your automation rules and identify any that do not provide specific value. Carefully assess each rule, discuss it with the automation rule owner, and determine if it genuinely adds value.
It is crucial to understand that the days of having single project rules for free are behind us. Check all rules from owners that may not be with your company anymore. Since rules do not have an expiration date, it is possible to be running rules that are not necessary anymore. Keep in mind that every successful rule execution will count against your monthly usage limits, so take the time to double-check the need/validity of each and every rule.
Since this change is inevitable, one of the steps you can take to minimize the impact on your team is to communicate these new changes effectively to all your ORG Admins, SITE Admins, and, most importantly, your project administrators.
Another measure you can implement is restricting the number of administrators at the site, organization, and, most importantly, at the project level. It is crucial as anyone with administrative access can create rules, which means they can potentially increase your expenses with Atlassian.
It is essential to ensure that every person who can create rules comprehends the impact of each automation rule they generate. This will help prevent reaching your usage limits quickly. So, for your own benefit, make a conscious effort to over-communicate these changes and ensure that everyone in your organization with automation rule-making privileges understands the consequences of their actions. Also, don’t forget to mention that you will review and clean up all the rules that do not add value.
Atlassian has also introduced a new feature that allows Jira administrators to control who can create automation rules. Go to the Global Automation setting within Jira and click on the ellipses next to “Create rule”. Select Global Configuration.
Here, you can configure if project administrators can create rules, or you can limit rule creation to a specific group.
Finally, analyze the cost of upgrading to Jira Premium or Enterprise if your company heavily relies on Automation Rules and frequently exceeds the monthly limits. Atlassian gives you a view of every Atlassian cloud product and how many rules have been executed within your current billing period. Conveniently, Atlassian has an upgrade button if you find yourself reaching your usage limits.
It is unfortunate that Atlassian is implementing these changes, and I am confident that these changes will affect nearly every Atlassian customer.
Hopefully, these tips will provide you with some guidance on how to better prepare yourself for the sudden change in Atlassian’s billing and usage structure.