We are currently aiming to unlock Jira as the work management tool of choice for all teams in an organisation, and to do that we need to address specific challenges that a broader set of teams face. This will create a much larger addressable market for Jira than what exists today.
By looking at non-technical teams, we have learned there is a strong need to streamline recurring work. The goal is to minimise the effort needed to duplicate tasks, improve work consistency and quality, and ensure important tasks are not missed, ultimately helping teams manage their workloads more efficiently.
We will be looking to meet the basic needs of users natively in the product and we will leave space left for app vendors and developers to solve for advanced use cases.
We have identified a number of recurring work capabilities for issues and projects…
recurring work based on cloning other existing work (note: we will research/test whether “clone” is the best term)
recurring work based on a calendar schedule
recurring work based on a workflowprocess
How we will solve this focus area
In the coming months, we will be further exploring and shipping basic experiences for issue cloning, issue scheduling, and process-based recurring issues this quarter. These will be available to customers in all editions
The automation platform will be leveraged for scheduling and for recurring work when an issue is completed. These will be facilitated through the creation of automation rules and the execution of these rules will count towards edition packaging limits.
Cloning projects will likely be delivered through the ability of customers to create their own project templates. This may only be available to Premium and Enterprise customers. We do not have a timeline to share for this right now.
Phase 1 (this quarter)
Cloning issues based on a workflow change (specifically when an issue is set to done)
Manually cloning issues
More clone inclusions
Bulk cloning
Cloning issues to another project
Scheduling single issues
Phase 2 (next quarter)
Date offsets
Field selection
Phase 3 (TBD on timing)
Creating a project from a customer-generated template
What we don’t have is full clarity right now and the final scope of these capabilities. Our intention is to cover the basic expectations of users in relation to setting up recurring work, and as we learn more about where this line is we will communicate this to you.
As of right now, we don’t expect to…
formally introduce a new issue template as part of this work
add any new functionality around input variables into the cloning process
offer cloning of work between instances
make these capabilities available in Data Center
Asks
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in:
Feedback on the recurring work capabilities
Feedback on the impact of these capabilities on an app you have
Any expectations you have around extensibility in this area
Any further questions we can try to answer or risk that you see
If you would like to discuss anything here with us directly or be kept informed of the scope and learnings as we progress through this work, you can also email me on eryan@atlassian.com.
Once again, similar to Action Items, Atlassian is working on a native feature in an area where many vendors have already built successful apps - and even entire businesses.
With Templating.app, we’ve focused on covering all the features mentioned in this RFC: managing recurring tasks with templates, whether for issues or projects. There are already great solutions available for customers in the Marketplace, offering enough variety to meet different needs and budgets.
Many vendors, including us, have invested heavily in this use case. Templating.app, for example, has been featured in several Atlassian talks due to our decision to fully embrace Atlassian Forge. Given the maturity of the Marketplace, it’s already a challenge to find truly new use cases. That’s why seeing Atlassian enter spaces where vendors are well-established feels a bit concerning. Depending on how deeply this feature is implemented, it could have a significant impact on vendors who have worked hard to build solutions in this area.
This isn’t easy feedback to share, but I hope it can lead to an open conversation about how we can continue to work on this together.
This RFC is deeply concerning for us as well. Two of our four apps on the Atlassian Marketplace (Duplicate Epic and Epic Clone) focus on cloning functionality and project templates, covering the exact use cases outlined in this RFC. If Atlassian implements these features as described, we actually could remove our two most popular apps from the Marketplace—apps that currently make up 90% of our revenue.
Like many other vendors, we have invested years of work into building these solutions, improving them based on customer feedback, and ensuring they fit a variety of use cases that Jira users rely on daily. There are already many vendors in the Marketplace offering similar solutions, and so far, there has been enough market share for all of them. Customers have been able to choose between different feature sets, pricing, and support levels to find the best fit for their needs. If Atlassian now introduces these features as native functionality, a large number of well-established apps will become redundant, significantly impacting many vendors who have built sustainable businesses around these use cases. We’ve built our apps with a strong focus on usability, flexibility, and integration with the Atlassian ecosystem, and this move raises serious concerns about the future of independent innovation in the Marketplace.
We understand that Atlassian continuously improves Jira, but given the increasing difficulty of finding new, viable app ideas in an already competitive Marketplace, seeing Atlassian enter spaces where multiple vendors have built strong businesses raises serious concerns about sustainability for Marketplace partners.
We hope this RFC leads to an open discussion about how Atlassian and Marketplace vendors can continue to work together without forcing successful apps—and businesses—out of the ecosystem.
Thanks Eoin and team for initiating this RFC. We see native features start to overlap more and more with existing Marketplace solutions and the current trend - its pace and depth - is very concerning for us.
Marketplace vendors have dedicated extensive effort and resources to build specialized solutions that address a wide range of customer use cases. This diversity of capabilities is one of Atlassian’s key differentiators, especially compared to competitors with less mature Marketplaces.
Repeated initiatives that replicate these third-party capabilities erode trust, reduce revenues for vendors in affected space, and can create confusion among customers who rely on existing solutions.
We’ve seen similar warnings in RFC-68: Action Items in Jira, and—in the spirit of constructive collaboration—we’d like to share our asks for Atlassian with you and the community:
1. Focus on core functionalities, minimize overlap
Keep native features foundational to address essential needs, and let app vendors continue delivering advanced or specialized capabilities. In this specific case, please consider which use cases we—and other listed apps—already satisfy effectively, and where there is genuine market demand for native solutions. 2. Extensibility
Provide well-documented APIs or Forge/Connect modules for recurring work features, so we can build seamless user experiences and advanced use cases on top of your groundwork. 3. Packaging
Reserve more sophisticated native functionality for Premium or Enterprise editions and leverage usage limits where appropriate, letting customers benefit from Atlassian’s modular platform without overshadowing specialized Marketplace apps. 4. Early and continued collaboration
Involve key Marketplace vendors early in your discovery, planning, and development phases for features that might overlap with existing solutions. That direct feedback loop fosters trust, aligns roadmaps, and produces better outcomes for our mutual customers. The sooner the better in these situations, and we hope this time our comments won’t come in too late to help shape your approach.
We appreciate the transparency and collaborative spirit you’ve show so far and understand the challenges of balancing native improvements with Marketplace growth.
Our team at Elements will be happy to discuss these ideas further and work with you over the coming months.
Hi Sarah. We can only apologise for there being overlap. The intention isn’t ever to create overlap, but in cases like this it’s possible as we react to strong asks from our customers on what they expect as native features. I understand the frustration and we’ll attempt to be as transparent as possible and make it clear where the point that basic needs have been satisfied. Thanks
Hi Jonas. Thanks for your message. We can aonly apologise for the problems this will cause you and we will aim to be as transparent as possible. We do expect there will be space left for app vendors and developers when it comes to recurring work. We want to cater for the majority when it comes to basic expectations users have when they are using the product. As the next month or so progresses we’ll get more clarity on where this line will be and we will share this.
We also hope with Jira moving to an organisation wide focus across all industries, there will be many opportunities that will open up that do not exist or are not big enough today with tech teams alone.
Regards,
Eoin
Hi Eoin,
Thank you for initiating the discussion for this RFC - it’s great to see that you are looking to provide as much transparency as possible. I also recognise the challange of balancing the native functionalities with the marketplace growth.
Together with Appfire team, we want to make sure that we collaborate on this topic closely in the upcoming months, as these changes might have impact on the Clone Plus for Jira app. I have reached out via e-mail to learn more details about it.
It seems necessary to have a serious discussion with Atlassian about the direction in which it has taken in recent times. It is evident that commenting on these RFCs is of little use, as feedback does not escalate to higher levels.
On one hand, we must keep up with the platform’s continuous breaking changes. On the other hand, Atlassian itself continues to cannibalize the marketplace by adding native functions that increasingly overlap with existing apps. All this while vendor feedback is completely ignored, and bugs and feature requests on ECOHELP continue to stagnate for decades.
These RFCs are limited to individual aspects. However, let’s consider all the RFCs together and the new features Atlassian launched and/or planned. The impact on the marketplace becomes significant, affecting many vendors and posing a considerable business risk. And this will likely worsen with upcoming announcements.
As vendors, we must unite to make our voices heard at a higher level within Atlassian’s hierarchy, requesting an official statement, as already proposed here: Atlassian Statement Request. Unfortunately, we do not have the contacts or the experience to lead this effort, but if someone were willing to draft a shared letter, we would be more than happy to sign it.
It’s strange that people expect that a RFC (Request for Comments) will result in Atlassian “doing as told (or asked)”. They are asking for comments.
Frankly speaking, as primarily an on-premise administrator and developer, I welcome these warranted native inclusions into the core product. The original “Clone” feature was created in the early 2000’s. Just because other vendors have heavily monetized improvements to Clone or Templates shouldn’t mean Atlassian has to keep their hands out of that arena.
Innovate and improve or get out.
Sorry for the rude post but JEEZE some of ya’ll are entitled as all heck.
If people act this way, it is out of experience with the RFC process. Out of the 81 RFC that came before this one, many were actually just announcements. In addition, Atlassian often only acts on the responses on the pre-defined “asks” and ignores other comments from partners. So the reason people act this way is because past interactions did not instil a lot of faith in the RFC process.
Nobody is saying that. What they are saying is that they would have like a heads-up. Personally I would have considered it common decency for Atlassian to have reached out to these vendors prior to a public post, and that Atlassian would have worked with these vendors to reach a point of mutual benefit.
You consider the vendors entitled, but in this case Atlassian is acting like a real asshole (pardon my French). For over a decade, Atlassian has encouraged vendors to “fill the gaps” and have profited from others doing so, not just in terms of revenue share but also in terms of making the product more interesting for customers.
I don’t see that as particularly relevant to the discussion. I don’t care much for Elon personally speaking, which is why I chose his unfunniest SNL clip as my avatar.
Yeah, as always Remi, I have a hard time disagreeing with you. I completely agree with that. Thanks for the enlightenment.
From the comments, it seems that Atlassian did not contact the affected vendors before publishing this RFC, and this is very sad as we’ve been told that it would change
The main issue with that is that Atlassian has completely ignored the extensibility part for a while, which means vendors cannot innovate and improve, unfortunately.
When Atlassian releases major features and platform changes, there are no APIs included, prime example for this is Automation API & integration with apps. They also often break existing APIs and extension points, resulting in poor app quality.
This is a continuation of this and numerous other threads, so Jira admins and users might not be fully aware of the language partners are speaking in this thread.
