Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
@Kevin Bui - Unlike most of the angry posts, for my client, this is a welcome change because they can live with the 5,000 executions per month for their JSM automations. The problem is they have today is that most of their projects utilize the same set of automations across all of the projects and that was causing them to exceed the previous 500 execution limit on Standard. Until we saw this announcement, we were going to have to re-implement these global automations on a project-by-project basis to avoid the limitation.
Their annual renewal doesn't come up until April, 2024. Can they take advantage of the new system before that renewal date? Otherwise, we have to break the automations apart and then put them back together in April.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Not to mention the lack of config features for workflows and other stuff which we use Automation to compensate for.
This kind of business decisions are so weird. Why such huge segmentation of product features between tiers? Just let people use the product they are paying for. It's not like Atlassian isnt making money, cause according to wikipedia, last years revenue was 3.53 BILLIONS.
I've noticed that people are discussing the use of workarounds to avoid using Automation, particularly by reverting to deprecated tools from before Automation was bundled. A notable example of this is the utilization of post-transition functions in workflows. Unfortunately, it appears that Atlassian is ahead of us in this regard, as my team has access to the beta version of the new workflow manager, and most of the post-functions are no longer supported. This creates unnecessary complications and hurdles for users who rely on these functions to streamline their workflows.
During the Team event earlier this year, my classmates and I were lamenting Atlassian's introduction of Team-Managed projects, which aimed to simplify and enhance efficiency. Instead of achieving the intended improvements, these changes have led to the removal of essential features and controls that are crucial for effective project management. Consequently, users have been forced to resort to automated workarounds, which, while feasible, are often tedious and time-consuming. With these Automation changes, even that is now broken.
I have been a strong advocate within my organization for the continued use and expansion of Atlassian tools. However, recent decisions have left me questioning our trust in these changes. We got our leadership team on board with using Product Discovery as an integral tool for project tracking, but I had to use Automation to fill in the gaps of such a new product. Now the hard limit is going to make JPD useless. I was considering getting some teams onto the Compass platform, but should I risk getting our team comfortable with a product if the cost can double overnight? Additionally, we are currently beta-testing Beacon for free; will that be an expensive proposition going forward? Should I instead focus my efforts on reducing our Atlassian cloud footprint?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
This seems like this could end up being a major productivity hurdle for companies looking to expand their Jira footprint. One of the advertised benefits of the Atlassian suite is the ability to create automations so we can eliminate manual overhead. This change will disincentivize that for orgs on the standard version. Separately, will this change impact integrations with other software like Gitlab?
@Kevin Bui I have been advocating Atlassian solutions for my company for the last 2 years. I'm disappointed A LOT. Several weeks ago you had a huge outage in automation, the bugs backlog is ENORMOUS.
Obviously, Atlassian is pushing its customers to take a closer look at Notion, ClickUp, or any other tool, that has predictable behavior and a consistent development path.
We can't afford Premium, because it's x2 from the current price. At the same time, you don't allow buying "extra automation". I'm not sure, that one day the API won't be "only for Enterprise", every team won't have a limit of ticket transitions per board, or users should pay per ticket view.
This is so frustrating. And the most disappointing part is that I can't really rely on Atlassian anymore, cause it's "updates" are breaking and non-consistent.
Thank you for the question. From 1st November, all customers will see the new usage page in automation based on the new model. Limits will be enforced on the next renewal date for products on an annual subscription and with quotes created before October. Trust this clarification helps. Please feel free to reach us if you have any further questions.
There are many more questions and concerns in this thread. Is Atlassian going to address them or from now on you answer only to questions that are content with your grand visions?
Also C_Derek Fields asked:
Can they take advantage of the new system before that renewal date? Otherwise, we have to break the automations apart and then put them back together in April.
And yet even though there are customers who are happy with this change and can reap some benefits, you still tell them: "Nope, why should you benefit from this earlier than before renewal date? Just break automations and put them together again in April."
Can we, as Atlassian´s customers, get some proper answers? The only relevant information that currently reached us regarding this change is, that Automations are under-monetized.
Thank you for the question. From 1st November, all customers will see the new usage page in automation based on the new model. Limits will be enforced on the next renewal date for products on an annual subscription and with quotes created before October. Trust this clarification helps.Please feel free to reach us if you have any further questions.
Based on the above I have a question:
This is an official response for this problem to all the Atlassian users? How can you "Thank" someone for a ....question in this case a useless change? No accept a debate only keep a "doggedness" and say ....TRUST in...whatever. What should we trust because there isn't a case impact study for it. Or this is based on: Please feel free to reach us if you have any further questions. This last part, in this context, sounds like a lot of arrogance.
Why should we bother to ask questions if you don't care about them? you don't consider them.
Sincerely, I'm very disappointed in how you treat this. From the marketing perspective, can you resume which is the Atlassian direction? Remember that users/customers make live this platform.
@Srini Chakravarthy you and Atlassian need to do better than just responding to one convenient question and ignoring the sheer rage currently on full display on this thread.
The longer you ignore grappling with this no doubt difficult situation for you and Atlassian, the harder it will be to fix it.
I sincerely hope your decision isn't to ignore it and hope we all go away. But that ain't happening.
I can only recommend that every person involved and affected here immediately escalates this as high up in their organisation as quickly as possible because the timeline on this is extremely short. Additionally if you have an Atlassian CSM, then get in touch with them and arrange a meeting, or create a support ticket to outline your concerns. If possible, do all three. I see this as one of the biggest changes for Jira Standard users ever introduced by Atlassian.
In response to my support ticket, I've highlighted that a large percentage of our automation rules are not there to improve our productivity, they are in fact there to make JSD work as a viable product in the first place.
Below is an extract from my reply detailing the automation rules we have "to make Jira work" which on their own exceed the 5,000 successful runs each month, and cannot in any way be optimised
Add users to their company – Add the organization to issues that the customer is associated to (this is a BASIC feature any service desk platform should do, that JSM does not without the use of automation rules)
Close linked Duplicates – When an issue is linked as a duplicate issue, close the duplicate issue. Again this is a basic concept of ticket merging that Jira doesn’t have, without using automation
Delete PNG & IMG attachments from comments – due to the AWFUL way Jira handles emails and embedded images, we have to use automation to delete these attachments so that we can see real attachments in the list and the attachment area doesn’t freeze due to there being thousands of tiny images from email signatures attached
Process Customer Feedback – Due to Jira not having the ability to brand its outbound emails for multiple brands, we are using a 3rd party email add on (more cost) this means we cannot use the inbuilt CSAT functionality. We have had to use a mixture of custom fields and the built in fields, with automation rules to tie it all together in order to use CSAT. Again, a feature that just works in other platforms.
Process Spam – There isn’t a built in way to quickly deal with a spam message without going through the entire workflow to close it. So this rule watches for a transition to “spam” and then follows the workflow to closure and resolution.
Set Brand – due to Jiras very limited email functionality we are using a 3rd party email Add on. This add on sends email branded as per a custom “brand” field. We use automation rules to say if the company is A, then apply Brand 1, if B, apply brand 2 etc
Set request type – We have two request types and two issue types (of the same name) this bizarre Jira separation means we need to use automation to say if the issue type is ticket, set the request type to ticket, if issue type is task, set request type to task
Append fields into description – the Jira search only indexes the summary and description, and does not search fields such as organisation and other custom fields, neither does it let us configure what fields are indexed, another of these "gathering interest since 2005" feature requests. Therefore we have to use this rule to add the contents of those fields to the body so it gets indexed and is searchable
Transition on Customer Update – unlike other service desk platforms, when a customer updates an issue, or emails in to a closed issue, the issue doesn’t change state. This rule re-opens closed issues on customer updates (a basic function other service desks just do!) and changes the state to customer updated if our state is waiting for customer.
The above automations exceed 5,000 successful executions per month, and these are not “nice to have” these are KEY TO MAKE YOUR PLATFORM FUNCTION.
If you enforce this limit, your product doesn’t function for us. We cannot “optimise” these anymore than they already are, its your product that needs optimising to mean we don’t have to use these automations in the first place.
Hello @Kevin Bui and Atlassian. It turns out interesting. I spent a month setting up the necessary automation for one process in our company, during which time I read a lot of articles and tasks that have NOT been solved for at least five years. You talk about “improving automation” on your end, but the tasks that project administrators ask you to do continue to be a crutch. "Thank you!" And instead of making our work better, you are increasingly putting a spoke in our wheels.
Tell me, why didn’t you report the changes half a year before the innovations? You give too little time, especially considering the fact that there are newcomers in companies and do not fully understand how to more comprehensively create automation rules.
This is going to be my last comment as this issue is costing too much time. Over the last 10 to 15 years I have promoted Atlassian products (I'm a beliver). Resulting into 10 to 15 core product sales at standard and premium levels.
The present implementations has been like a rolling stone. The CEO is completely against Atlassian products. None the less we have rolled out Jira's standard and confluence product's with a 25 user base and are now looking at including service desk and or opsgenie. We finally now have buy in from all users in all verticals within our company (sunny days).
Due to limitation in Jira we have had to invent a couple of work arounds example by project prioritization, hiding status on only some create screens, copying more than one cascaded field from one issue to anther, depending on status moving one project to another (by the way have a sneaky cheat for this if anyone wants it ) and living with the one which we have not found a work around showing certain epics only in certain projects and not globally.
With four major projects coming up between now and Christmas like hell am i going to review refine all automations (which so far we have built at project level) in six weeks especially if the tool is "supposedly" going to be available in two and no way will the finance allow us to move to premium.
Not long ago when I was lead working on a global SaaS platform with multinational customers I made the rookie mistake of applying fees on a an already existing feature with the promise to the customers of a greater return in functionality at some time in the future "undefined features and time line" (oh boy) what a mistake <sound familiar right>. Is there some one new at Atlassian driving business (making the same rookie mistake). If there is, they have no idea of their customer base and what it means for us to be able to be part off and promote the Atlassian stable. Or is it the case that finance want to buy Mike and Scott a new iphone for Christmas ?
Come on Atlassian this has got to be one of the worse decision ever and goes completely against the Jira sprit. By the way the last project of the four mentioned above already is being penned on freshdesk. Is this the end for Jira for me? (the CEO hopes so)
Oh and a bonus pm with the five song lyrics in this text and i will give you five successful automations and 5 transition for free !!
It's important to note that we've historically under-monetized automation while still investing in making our automation more flexible and powerful for customers. Customers like yourselves have been getting a high value capability for a below market price point for quite some time.
This is the most honest answer we have had in this thread. Don't be mad at them for that, we should encourage more truthfulness.
Sadly, looking through Q4 FY23 letter to shareholders, it seems if you are not a Fortune 500k company they don't aim to serve you (emphasis mine):
And as a result of the macroeconomic environment, we’ve had to make thoughtful tradeoffs this year, including consciously shifting marketing resources to prioritize growth in customers with the highest lifetime value. The great news is, we’re seeing this strategy pay off.
As a volume-based business, we aim to serve the “Fortune 500,000.” That’s what our flywheel-led GTM motion is designed for, and that’s not going to change. However, we’re constantly improving our enterprise capabilities and evolving the higher-touch motions that help us make deeper inroads with enterprise customers.
I have been a Jira advocate for nearly 10 years now, but these changes are having me reconsider.
Atlassian, it doesn't have to be this way. If the operating cost of unlimited automation's is too much, which appears to me to be the actual root problem here, let's have an honest conversation. Dealing with increased costs is understandable.
It is okay to say you need to re-think automation monetization because of increasing costs + new products and functionality added (our fears of doing this on other features aside...).
However, breaking users workflows and automations, then having the audacity to sell it to us as simpler and more efficient is not okay.
Looking at the number of views and comments, there are clearly many people that have put months to years of work into automations. I feel it is safe to say you are easily imposing 100people x 1year = hundreds of years of work, if not thousands, to deal with this change just to stay the same.
Summarizing some of the examples brought up, there are several ways to monetize that don't break peoples workflow:
Update your already existing service limits i.e. tune daily processing time (60min per 12hrs), items queued globally (50k), etc. This could even be variable based on user count.
Charge a cost per usage > limit if you go over.
Buy tiers of automation rules (not tied to plan or user count).
A hard-limit that breaks peoples functionality is bad. Some people may accidentally blow out their usage in the first week, then they are just hosed for the rest of the month?
A soft-limit that tunes usage based on global queue size, processing time limits, priority, etc...then just delays usage (not blocks) is far better practice.
What is also not clear to me: If I have 3 rules x 2 actions each, is this 3 or 6 usage?
If 3, then you have just incentivized people to make 1 complicated rule with 6 actions. This will have people making rules that are harder to maintain, buggy, and with longer run time. Longer running rules leads to more queue/process hogging, making automation's less responsive and delayed. This seems like the opposite of the optimization you are looking for.
If 6, then our usage is exploding far higher than we estimated and it's worse than we thought.
Please reconsider. You can do better. With >750million in Profit for Q4'23 you could, if you wanted, find a solution for both the Fortune 500k and small businesses.
Also, it hardly seems fair that a 1000 user-installation (as ours) get the same amount of rule runs on the standard tier (upgrading to Premium is extremely expensive for us - since we're a consultancy and 600 of the users we pay full price for(!) are actually our customers who only have light usage) as an installation with 15 users!
Just adding my voice in here. I am particularly disappointed to see the change in single project automations being included int he charge.
This is really going to limit my companies usage of Automations going forward, as there is little to no hope of us moving to the premium tier of Jira.
I have never been a great lover of Atlassian's product line, but in recent years between Confluence and improvements to the general user experience of Jira (especialy thank to Automations) I have been growing in my enthuasiasm towards their products. I was even going to begin making a case for using some of the newer offerings they have.
But this has thrown that out the window. I am going to be looking elsewhere.
This is such an awful business strategy. Put a great tool (Automation) in the hands of your users, with an unlimited number of runs per project, let your users take advantage of the tool, and then, bang, say the party's over and try to get everyone to switch to Enterprise.
We will have to remove all our automations and find an alternative tool. What a waste of time and energy.
I wonder how many people commenting are aware of the plans to finally add reporting for Assets (formerly Insight) with their new analytics product rather than adding to the app. I asked in https://jira.atlassian.com/browse/JSDCLOUD-9930 if we'd have to pay extra for Analytics or if it would be included for free and never got an answer.
We have a 140 user JSM license and were considering Jira software for project management. With this news I can confidently say that we will look elsewhere. You can fool me once Atlassian, but that's it.
453 comments