RFC-30: Restructuring Categories on Atlassian Marketplace

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas , but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project:

We are making changes to the category taxonomy and introducing the concept of keyword tags to improve the discoverability of apps in Marketplace.

  • Publish: Oct 20, 2023
  • Discuss: Nov 3, 2023
  • Resolve: Nov 10, 2023


We understand that the current categorization system in the Atlassian Marketplace is complex and disoriented with 37 categories. This offers a disjointed experience for customers who are trying to discover apps that align with their needs.

The existing categories are inconsistent with some being too broad and some being too specific based on use cases, functions, and/or features. The current system also lacks clear guidance for Marketplace partners on how to categorize their apps, leading to potential misalignment and confusion. Below are the issues that have been identified due to this complexity:

  • Only a small percentage of customers use categories as they do not find value in them
  • The same apps are found in multiple categories, thus impacting app discoverability
  • Apps are shown in categories which they don’t fully align with
  • The number of use case-based categories is limited, and as a result, customers cannot refine their search based on the use cases they are looking for
  • Current categorization is broken and hampers proper segmentation of apps. This is a blocker for proposing recommendations like ‘similar apps’ to customers

Proposed Solution

Categories and Keywords
The Atlassian Marketplace will feature industry standard categories and use-case-based keywords. We will reduce the number of categories to 10, which will be exhaustive enough to cover all existing categories while being inclusive at the same time. Along with categories, we will also provide 60+ keywords that can be used to showcase use cases supported by an app. In the newly proposed taxonomy, partners will be able to tag their app to 1 Category and 3 keywords. The limited number of categories will make it easier for customers to navigate, while the higher number of keywords will provide flexibility in refining their selection based on their needs and requirements. For example, an app can be categorized as Project Management and have additional keywords such as Issue Tracking, Dashboard Gadgets, and Data Visualization.

New taxonomy for categories

Currently, when people click on a category (for example, time tracking) they are taken to a filtered page of search results for that category. We will instead create pages that provide context and showcase content about the specific category. Thus, each category will have a dedicated page in the navigation. Partners can map their apps to one category and detailed documentation on how to categorize will be provided to support the partners in this process (tentatively by Dec 1, 2023). The app would be discoverable on other surfaces based on the keywords provided by Marketplace partners which will be searchable.

Here is the list of categories along with a brief description of each of them:


Keywords are a new concept that we are introducing in the Marketplace. Partners will have the opportunity to choose up to three keywords for their apps. A comprehensive list of keywords will be provided for easy navigation for the partners. The pre-defined list is curated to ensure clarity and consistency without any duplication.

We understand that we might not be able to cover every possible use case that aligns with app offerings on the Marketplace. For this, we will be sharing a detailed process for Marketplace partners to get new keywords added in case use-cases supported by their apps are not provided in the list of keywords.

Here is the list of pre-defined keywords:

How will the new system deliver value?


Customers will derive value from the quick and efficient discoverability of the apps. Previously, customers used to see the same set of apps in multiple categories and they didn’t have a way to filter the results based on different use cases. The new experience will encourage intent-based discoverability and customers will be able to find the right apps that suit their needs and requirements. The new taxonomy and keyword strategy will support effective search and filtering experiences for customers.


Partners will be able to reach their target customers by accurately defining keywords for their apps. The new system offers a wider range of use cases that precisely represent the customers’ needs. For instance, an app that supports notifications for JSM can be easily discovered by users if it is categorized under ‘IT support and service’ and has a keyword called ‘Notifications’. The new experience will help partners connect their apps to the right audience and the apps will be aptly discoverable under the selected category.

Change Management

For smooth transition of all apps from the old system to the new category taxonomy, we will have a change management period of 3 months (tentatively December - March). Throughout this period, we will offer support for the old categories and ensure that there is no disruption to the customer experience. Customers will still be able to navigate the Marketplace using the old categories.

For existing apps, partners can go to the app details page and edit the information by choosing the new category and three keywords. Apps that are not categorized will not be displayed on the new category pages that will be created as part of customer-facing launch, which is scheduled post the change management period in March 2024 (tentatively).

New categorization on App Details UI

Once the change management period concludes, we will start transitioning to the new category taxonomy on the customer side. The customer experience will take the users to dedicated category pages with keyword filters so that they can find the app they need.


While we would appreciate any reactions you have to this RFC (comments, questions, or concerns about the proposed changes), we’re especially interested in learning more about:

  1. Are there any concerns with the proposed taxonomy? Do you foresee any edge case scenarios that we have missed, which have the scope to be a separate category?
  2. Are there any concerns with the keywords shown in the RFC? Are we missing any keywords that don’t overlap with those listed above?
  3. Any feedback regarding change management?

We appreciate your time and any feedback you could provide, whether it be on the specific points highlighted above or anything else outlined in the RFC. Your valuable insights will play a significant role in shaping better app discoverability on the Marketplace.


Hi @ChoppaAditya ,
thanks for the RFC.
I have one ask: Can you add a category called “Other”? That allows apps which don’t fit into a category to still have one.

Minor request: Can the description of the “Security and compliance” category be expanded for all forms of compliance, not just privacy? The marketplace contains apps that support regulatory compliance in the financial, life science, and other heavily regulated industries where compliance isn’t privacy-related.

Minor detail, but it would make it more likely for those apps to be categorized into the same place, rather than being spread across “Security and compliance”, “Administrative tools”, and “Other” (if that’s added).


Project Management is most likely associated with Jira & Co.

We have a Bitbucket pull request management app. This app does not fall into Software Development category.

IMO the 3 keywords limit does not justify a complex app that helps development leads/managers, developers, compliance and Devops folks. We want the app to be visible to a wider customer base with complex requirements.

I concur with @AaronMorris1 that the compliance category scope is wayyyy too narrow. Compliance is becoming an overarching topic that affects many more aspects than the ones listed.


We have a broad-ranging app (Microsoft 365 for Jira) that solves very different use cases and cannot be defined within only one category.

It’s strong in all three columns of Atlassians strategy: ITSM, agile dev and work management – and we’ve invested the last year to built strong use cases within our app for all three of these workstreams.

Even if you see categories not as use cases but as functionality, it fits in project management as well as communication (although “Content and communication” is a weird stretch) and IT support or customer relations… it has plenty features.

As for keywords – I’m finding 10 keywords in that list, which would fit our app perfectly. So, three is very limited.

I think these restrictions work well for narrower apps, not for full-circle solutions. I don`t see why customers shouldn’t find apps in the fitting category or keyword - and a limitation of such kind would necessarily mean that some categories would be missing in our case.


What is the outcome you are hoping to achieve from this change? How will you measure it?

How will customers interact with keywords in the Marketplace? A filter or drop down list?

How will this impact the way the search algorithm works for free-text searches?

Do keywords map to categories? Will Partners be restricted from selecting some keywords?

How will keywords and categories interact with existing filters?

Pre-defined keywords are essentially categories in disguise. So while I’m in favour of reducing the number of categories I would prefer to retain the current free-text search algorithm remain in place. You will probably find users gravitate towards the search box regardless.


I am very surprised with the proposed changes, and totally align with @SeanBlake 's question around the expected outcome.
I’d add:
How does these changes fit in the broader discoverability strategy Atlassian is willing to set up to help customers navigate their apps needs?

What insights drew you to the conclusions and changes you’re planning ? would you be willing to share them as context for giving you better feedback?

Is self-declared categorization still relevant in the age of generative AI? Couldn’t you be much more dynamic in how you recommend apps to customers ?

We feel the conclusion about mapping an app to just one category and a set of 3 keywords as really restrictive: our products cater to a variety of use-cases, and customers have different approaches to discovering them through their journey.
There are several apps in our portfolio I wouldn’t know where to put, because at least three categories would be a great fit for a particular set of customers.
We believe this " The same apps are found in multiple categories", if executed correctly, shouldn’t impair discoverability, but rather help customers find what they look for in their own way.


Allowing to map an app to only one category is too restrictive in my opinion: on the Time Tracking example - I see at least 3 categories that I’d select to find such an app in the marketplace as most Time Tracking apps serve those purposes (project management, software development, data and analytics).
@ChoppaAditya how this change will affect the order of apps in the marketplace? Currently the order in categories is completely random, will that change as well?

  1. We also think choosing only one category for our product is impossible. Our app is Content Formatting Macros for Confluence (by Kolekti). It offers functionality for at least 3 categories:
  • Content and communication (our app helps to format content for better team communication)
  • Design (our app includes macros for design content improvement)
  • HR and team wellbeing (content formatting for onboarding)
    Also, it would be difficult to use only 3 keywords, because all these work for us: Communication, Collaboration, Customization, Design, Document Management, Knowledge base, Knowledge management, Theme and Styles.
  1. What apps will be on the Atlassian marketplace home page in the section where are apps with Staff Picks now?

It sounds to me that the Keywords are purely related to the categories and not the wider site search function? I assume the main search functionality will not change, and results will still be displayed based on the user’s search rather than trying to assign that search to one of the 60 keywords?

I.e. currently, the App name and description heavily affect results in the user search, and I assume this does not change?


2. Are there any concerns with the keywords shown in the RFC? Are we missing any keywords that don’t overlap with those listed above?

At 55Degrees, we have a few apps to help with flow metrics and most of all forecasting outcomes based on what you have done in the past. The main keyword we would need for those apps is "Forecasting”.

Hi, I agree with Sean’s questions. Can you please give us more information about the expected outcome? Isn’t it a bit too restrictive to allow only one category? What is the plan for the apps that don’t fit into any categories released? What will happen if there are overlaps between categories? What is the best way to choose the category then? And can you please give us more details on how these changes will affect the search algorithm?

Hi, we at Tempo have lot’s of questions about the proposed changes.

  • What’s the expected outcome?
  • What criteria will be used to decide that the new category search is ready for a customer launch?
  • Will there be a testing period for app vendors to evaluate that their apps are showing up appropriately?
  • Will you provide vendors a template and be able to show the impact of these changes?
  • What is each of our search volumes today and for what terms for each of our listings?
  • What are the search volumes for the proposed new categories and keywords so we can understand the implications?
  • What are our top keywords in the Atlassian Marketplace?
  • How would this impact our google search results for the marketplace?
  • Do you want larger vendors to rely less on the marketplace and more on our own organic and paid strategy?
    ** Ex: Large partners drive the buyer journey and send people to the AMP as basically just a sign up button and pricing page?
  • What is the anticipated downstream Google impact of these changes and do we need to change our listing titles and content to align with the new categories/keywords?

Similar to the other replies, we find the proposed categories to be limiting and the list of keywords to be a mix of: features, capabilities, categories, use cases, characteristics, markets, and industries.

  • It would be helpful to have an information architecture/hierarchy for search terms

There is no mention of alignment to Atlassian’s strategic themes:

  • Work Management
  • IT Service Management
  • Agile and DevOps
  • For example, the first thing a customer sees today when they go to atlassian.com is a message that says Atlassian solutions are designed for all types of work, immediately followed by the list of EWM, ITSM, and Agile & DevOps

We’re concerned the narrow list works against aligning Marketplace Partners to Atlassian and Solution Partners, who are focused on the strategic themes and rolling out solutions, especially to enterprise customers. We need to be part of that GTM motion.

Directly from our Marketing organization:

  • “Google, Gartner, G2, and AWS Marketplace all list out products across multiple keywords/categories”
  • “Did a mapping of which 3 keywords would apply to each of our products and there’s not enough to choose from”
  • "Given there are 5000+ apps in the marketplace, more keywords would be helpful… such as:
    ** financial management
    ** cost management
    ** forecasting
    ** resource management
    ** etc
  • More use case filters, like ITSM, professional services, SAFe, etc.

@ChoppaAditya The team at Tempo gladly volunteers to discuss further. These are significant changes your are considering. Please reach out, we have lots to share to help all partners grow in the marketplace.


Hi Atlassian team, thanks for the opportunity to provide feedback. On the Gliffy team, we have some concerns.

First, a large portion of our traffic comes from folks navigating the Atlassian Marketplace, so understanding the impact, goal, and results of any changes here is valuable to us. As Alex @ Tempo mentioned, issues in which we aren’t showing up appropriately can very negatively affect our business, so I’d like more detail on the transition period so that we can monitor appropriately. I would also like to understand the path to resolve any issues as they arise and a commitment to how quickly we could expect a resolution.

With regards to the actual categories and proposals, I think selecting just one category may be too restrictive based on my knowledge of the marketplace broadly. While I understand there’s a desire to better clarify the categories, it might be nice to allow vendors to select a primary category and then 1-2 additional secondary categories — perhaps these would be weighted differently than the primary category in terms of how/where the apps show up.

I think it would additionally be helpful if Atlassian provided a statement for the keywords. For example, I would argue that Gliffy’s use cases can fit communication, collaboration, diagramming, knowledge management, knowledge base… If we are limited to 3, I think understanding how these keywords are defined/understood by the user would support us in being effective in meeting your Marketplace user’s needs.

Last, would there be an approval process or a qualification process for the keywords apps can use? I’m thinking about G2, in which they publish the features/requirements expected of apps in a specific category.



I salute the initiative to clarify how apps are categorized, but do have a few concerns about how to categorize broad apps that could be in multiple categories, like @anke.viehweger . If the goal is for customers to find similar apps together, but partners making similar apps choose different categories, customers could find similar apps across multiple categories, which does not improve the situation. Are there any plans to mitigate this?

I would second @SamieKaufmanGliffy 's suggestions of a secondary category, as well as some guidelines/definitions for keywords to make sure apps are coherently categorized.

I’m also wondering if the announced category pages will replace the collections pages (for example, document management). Collections could be selected as one of the staff pick options, and as I know the staff pick program is being rebooted, what will become of the collections pages?

1 Like

Thank you for allowing the community to provide feedback on these proposed changes. We here at Appfire have some questions and concerns, as many of our apps fall into multiple categories, which we see as valuable.

  • Only a small percentage of customers use categories as they do not find value in them.
    • Is there data behind this? If this is the case, maybe there shouldn’t be categories but use cases and keywords that align with the Atlassian solutions - ITSM, Work Management, and Agile & DevOps.
  • The same apps are found in multiple categories, thus impacting app discoverability
    • The value we see here is if someone is searching for an app for a specific category, they may find an app they already have but are not using to its full potential, which could save them money (and promote brand loyalty). For example, Comala Document Management would fall under many categories - we have several organizations that use it for security & compliance, content & communication, and HR & team well-being. We do not want to dictate how the app should be used. The same can be said with our other apps, like JMWE and PowerScripts to name a couple of many.
  • Apps are shown in categories that they don’t fully align with
    • If this is a problem, a vetting process could exist before assigning categories. Perhaps apps must meet identified criteria to fit into that category.
  • The number of use case-based categories is limited, and as a result, customers cannot refine their search based on the use cases they are looking for
    • Is it possible for keywords to be assigned to categories so that when users filter by category, the keywords drive the logic? Do you have more details on how this will affect app findability? We’re very interested to see how the proposed changes would impact browsing and search behavior. We’d love to see some mockups of the new customer experiemce.

While we agree that there is a better way to move forward, as many others have already commented, we see many limitations with the proposed changes. Looking at competitive marketplaces, there are several ways to filter, with apps showing up in multiple places. Further, other marketplaces focus more on industry wide terminology. We’re happy to provide more feedback as the community’s comments are considered.


How about building an AI-based app finder that scans MP and creates embeddings based on description and highlights text content for each listing. Then customers can ‘ask’ or search for app suggestions based on their plain text requirements. To stay backwards compatible, categories and keywords are still an option for filtering.

1 Like

Thanks for all the thoughtful contribution! I ran really late with closing for discussion and a few comments came in after. We’re even a couple weeks past the resolution date now. I’ll be following up with @ChoppaAditya and team to get a resolution to the questions & concerns raised here.