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
Atlassian is evolving its platform to make the Teams app the central hub for discovering people, teams, and their work. This RFC proposes enabling extensibility of the Teams directory via Forge, allowing developers to build apps that enhance user and team profiles, integrate contextual data, and unlock new use cases for customers.
Publish: Oct 08 2025
Discuss: Oct 22 2025
Resolve: Nov 06 2025
Problem
With this move Atlassian is hoping that the Teams directory will become the primary interface for organisational people and team information. Making the Teams directory extensible via Forge will allow:
Customisation of user and team profiles (e.g., adding badges, on-call status, custom fields etc)
Integration with other Atlassian and third-party systems
Faster innovation cycles and customer-driven improvements
As Forge is designed for secure, scalable extensibility. Enabling Forge on the Teams directory allows developers to build and distribute apps that enhance the experience for all Atlassian customers.
Proposal
Enable Forge extensibility for Teams by:
Defining extension points on user and team profiles (e.g., tabs but potentially panels, cards, fields)
Providing APIs and context for apps to access profile, team, and organisation data securely
Example use cases
Badges for user achievements
Displaying vacation status on user profile or team calendar on team profile
On-call rotation info in the user or team profile
Integration with other Atlassian products and third-party tools such as Google Drive
Team health dashboard such as display, retrospectives, velocity etc
Below are a few purely directional design examples.
Example 1 : Example of building third party extensions through the form of tabs in the team profile page.
We have apps enriching user-profiles in Jira and Confluence with data coming from the corresponding Microsoft accounts, so we are greatly interested in this RFC. Some first questions that come to mind:
How will this affect displayed user data in Jira and Confluence (and other “products”)?
For Confluence, there is macro “User Profile”. Will/can this be extended?
How about the popups when hovering over a user? Will/can they be extended?
I second the need for extending the popups when hovering over a user in Jira/Confluence. We used to have apps in this space and customers were very interested in extending those popups.
Also, will those apps extending the Teams app be able to monetize on the Atlassian Marketplace? Will those apps be coupled to Jira/Confluence/other Atlassian apps and be compatible with Cross-product-apps (which is now probably called Cross-app-apps)?
As we provide an app that enables custom fields for Jira — whether functional, calculated, or graphical - we’d love to bring the same capabilities to team and user pages.
To achieve this, we’d need entry points where our app can render custom fields and allow users to edit their values. In addition, we’d require a module for configuration pages, so that admins can, for example, define the appearance of fields or assign specific fields to certain users.
What about technical events, like USER_CREATED, TEAM_CREATED, TEAM_UPDATED, USER_REMOVED etc? Will there be such a thing? Would be helpful for apps to be able to react to such events.
How can profile data be extended? I’m not talking about separate panels/cards, but extending the existing “About”-data on a profile with additional “fields”:
Hi @YY1 , thanks for the feedback. That’s an awesome use case, love the app! I’ve created a suggestion ticket here so our team can track this, could you please vote and comment on it with your use case?
How will this affect displayed user data in Jira and Confluence (and other “products”)?
For Confluence, there is macro “User Profile”. Will/can this be extended?
How about the popups when hovering over a user? Will/can they be extended?
Confluence macros are a core feature of Confluence so they will not be extended as a part of User/Teams extensibility
The popups is a possibility. We could build extension points in the user profile and have it reflected there. What are your use cases here? i.e. What would you like to show these user popups and why?
Thank you for the feedback. Understood, what custom fields are you interested in bringing to team and user pages and why? Are you able to elaborate on your use cases?
Thanks for this long awaited RFC - here’s our take on your questions:
What Atlassian and third party tools would you want to contextually integrate to support your team workflows?
Utoolity specializes on integrating AWS with the Atlassian platform, so we’d like to surface AWS resources that are owned by or relevant to each team’s workflows.
What are some of the use cases that you would solve? For example, I want to be able to view team health
As a developer, I want to access the AWS resources comprising the environments of our workloads
As an operator, I want to visualize the AWS metrics comprising the health of our workloads
What extension points would be most useful to your customers (tabs vs. panels vs. cards)?
Your order matches the envisioned progressively improving depth of the integration (which presumably applies to most partners integrating 3rd party products):
Tabs provide the basic canvas to comprehensively surface 3rd party resources owned by or relevant to the team
Panels would be a more light weight alternative in the absence of tabs
Cards are probably too small for the majority of our use cases, still potential entry points to more detailed metrics and dashboards in the 3rd party console
What governance is needed for third-party apps in profile contexts? Team and User?
Team is most relevant in our case, given AWS resources are more commonly managed/owned/accessible by a team rather than a single user. Regardless the user is still a valuable context that would allow narrowing down the relevant data, but this is definitely a later priority for us.
@AprilChi, care to answer those questions as well? I’m especially interesting in technical events about users and teams. Possible use-cases for that is to listen to changes to users/teams and react to that somehow: Sending onboarding material, creating initial pages, adding to groups/spaces/pages, etc.
