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!
Project Summary
We are evolving our new Customer Service Management app to offer extensibility and enable partners to build custom solutions for any customer need. This RFC proposes enabling CSM app extensibility via Forge, allowing developers to build apps that customise customer and agent experiences, integrate contextual data, and unlock new use cases.
Publish: January 15th 2026
Discuss: January 29th 2026
Resolve: February 11th 2026
Problem
As customers scale their support operations, they need tailored experiences and deeper integrations across their customer portal and agent workflows. Making CSM extensible via Forge will allow:
Customisation of customer and agent experiences (e.g., request and agent view panels, customer/org profile enrichments, dynamic SLAs and queue insights)
Integration with third-party systems (e.g., CRM, CCaaS/telephony, billing/commerce)
Workforce Engagement Management (WEM) extensions that optimise operations (e.g., time tracking and schedule visibility, QA scorecards and coaching hooks)
Proposed Solution
Enable Forge extensibility for CSM by:
Establishing a marketplace category for CSM to increase discoverability of apps
Providing additional APIs and webhooks to read/write customer and organisation data and react to key lifecycle changes (Existing API documentation can be found here)
Defining extension points across agent views and external facing customer experiences
What are some of the use cases that you would solve?
What APIs and extension points would be most useful to you and your customers?
What Atlassian and third party tools would you want to contextually integrate?
How to Give Feedback
Please comment directly on this RFC thread and share your use cases, suggestions, and concerns to help shape the future of extensibility for Atlassian’s CSM app
Thanks for sharing this RFC, this is a very welcome discussion.
In Jira Service Management, it’s currently possible to surface contextual UI to customers on the request detail view using portal extension points such as jiraServiceManagement:portalRequestDetail.
With Customer Service Management, we’ve observed that these JSM portal modules do not render in the CSM portal experience, even though they work in classic/new JSM portals.
My question is:
Do you plan to support Forge UI extension points in the CSM portal that are functionally equivalent to portalRequestDetail(i.e. allowing vendors to inject contextual UI in the request detail view for customers)?
If yes, is the intention to:
– reuse existing JSM portal modules, or
– introduce CSM-specific portal modules / extension points?
Any clarification on roadmap or intended patterns would be greatly appreciated.
Slightly out of scope, but closely related to portal Extensibility:
Is the CSM portal UI the long-term direction for Jira Service Management portals as well, meaning that JSM portals are expected to eventually adopt the same layout (without a right panel)?
This is particularly relevant for extensions relying on jiraServiceManagement:portalRequestDetailPanel.
Thank you for sharing this RFC and giving the community the opportunity to provide feedback.
We have existing Forge apps for JSM that allow customers to view additional fields
on their requests and edit them after submission, without requiring agent intervention.
We would like to bring similar capabilities to CSM.
For CSM, we need:
APIs to read and update request fields for portal customers, with support for both asApp() and asUser() for all CSM-related APIs — enabling proper customer attribution
when customers modify their own data. This includes:
Request form fields (text, select, multi-select, date, etc.)
Comments (create, edit, delete)
Attachments
Portal extension points similar to the JSM modules we currently use
(e.g., jiraServiceManagement:portalSubheader, jiraServiceManagement:portalRequestDetail)
that allow rendering custom UI within CSM customer experiences
Access to customer context (viewing user, permissions, entitlements)
Clarifications needed:
Will existing JSM portal modules render in CSM, or are new CSM-specific modules planned?
Can a single Forge app include modules for both JSM and CSM in the same manifest?
Hi @FabienPenchenat and @FlixAndre , thank you very much for commenting and the feedback. As very rightly pointed out, there are a lot of elements that JSM and CSM have in common, as we leveraged a lot of the JSM and wider Jira platform as a base.
To answer your questions - generally speaking, yes, we do want to offer extensibility for the request view, both on the customer, as well as the agent side. Whilst still up for debate (and we’re definitely open for feedback) - we do anticipate we will be introducing CSM specific extension points to allow for more targeted/specialised extensibility and a clear differentiation between JSM and CSM. Keen to understand if you have any preferences and why?
Would also love to know which surfaces and events are must-have vs nice-to-haves for you, and whether there are any gaps you see in JSM’s extensibility today that you think we could or should avoid and/or close with CSM?
Thanks again, and please do keep the feedback coming!
Hi @francis , you are definitely right! It’s a common request from our customers, both when migrating from another CS solution, as well as ongoing syncs with external CRM systems.
For now, we don’t have immediate plans to build out 3p connectors internally, although we do have ambitions for CSM’s customer directory to be linked to TwG and existing Atlassian connectors, as well as other internal tools like Assets which may already house some of this data.
If you consider building any integrations, would love to hear what you would need beyond these APIs? Any specific extension points or capabilities that would help?
Hey @ggachev Thanks for sharing these details! I mentioned this in a previous reply just then, but repeating here to make sure you get this too - we are leaning towards introducing CSM specific extension points. For forms especially we will likely have to as CSM forms work differently to JSM. Keen to hear if you have any preference and if so why though!
In the context of our app, whether on JSM or CSM, we are currently addressing exactly the same need. At this stage, we don’t have different or specific expectations for CSM compared to JSM.
Concretely, our primary requirement is the ability to dynamically display a small form on the customer side, enabled on demand by an administrator and only for certain customers or in specific contexts.
For this to work properly, we really need an equivalent to jiraServiceManagement:portalRequestDetail, or a comparable extension point at the request detail view level on the portal side.
Extensibility at this specific point in the experience is therefore key for us.
Thanks for sharing this @DorotheaLinneweber! From Refined’s perspective this is very relevant and welcomed.
Understanding the current state
Do I understand correctly that creating and viewing requests will continue to work through the Jira REST APIs, and that this is expected to remain supported going forward?
App / Extension model
For this kind of capability, it feels more natural for us to think about it as an extension of the Service Collection solution, or potentially a “helper app” use case, rather than introducing a new app category on the Marketplace.
I’d also assume that other Marketplace vendors would want to extend the customer or agent experience they already provide on top of JSM. In many cases, this wouldn’t naturally map to a standalone app, but rather something that complements what Atlassian already only sells as a Collection.
Related to that: is the “helper app” concept from earlier RFCs still something that’s being actively considered?
Extensibility
A key use case for us would be embedding the Customer Experience AI Agent directly into customer-facing Refined sites (e.g. branded help centers).
We’d also be interested in reading and writing customer data as part of the request creation flow on our sites
