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
Also, I know it’s probably still very early, but do you have any visibility on the current adoption of CSM?
We’re trying to understand how far along customers are and how embedded the product already is in real-world setups. Any high-level insights would be really helpful.
Hi @ThereseAlburg ! Thank you so much for your feedback!
To answer a couple of your questions more explicitly:
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?
Yes, that is correct
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 are in the final stages of dogfooding the ability to embed the AI chat widget on external websites. This will launch as a new channel ‘Embed’ over the coming weeks.
Hi @FabienPenchenat With CSM being tied to Service Collection we have a range of maturity implementations - there is a number of customers who are only just being moved onto Service Collection and are very early in their journey, but we also have some keen early adopters who have gone live and already made the move to shift their customer service onto our app.
Generally speaking we know that moving customer support to a new tool is often a very considerate and careful given it is crucial for brand satisfaction and loyalty
Thank you all again for providing such detailed and thoughtful feedback! We will now close this RFC.
In terms of next steps, we are working through onboarding CSM to Forge, and will introduce CSM specific extension points to support CRM integrations, as well as the external facing request view and form.
As we do so, we will update our documentation, and changelogs - please stay tuned!
Thank you for sharing this RFC. As a Marketplace Partner, I would like to share some feedback and raise a few questions regarding the roadmap and strategy for Customer Service Management (CSM).
1. Market Adoption & Product Maturity
Echoing the question already asked by @FabienPenchenat, I would like to ask about the current adoption of CSM, specifically among Enterprise customers. Following discussions on the Atlassian Community and the Atlassian Champions Slack channels, the current sentiment paints a picture of a product that feels somewhat immature compared to JSM, and potentially not yet ready for complex production environments.
Furthermore, the vision distinguishing JSM from CSM is still not entirely clear to us. Specifically:
When should we recommend one over the other?
Is the current adoption driven by greenfield projects (started from scratch) or migrations from existing JSM instances?
This information is crucial for us to estimate the potential churn of current clients using our JSM-specific apps and to prioritize our development roadmap effectively.
2. Marketplace Presence & Vendor Strategy
We need clarity on how CSM apps will be presented on the Atlassian Marketplace to avoid customer confusion and negative reviews.
Discovery: Currently, filters focus on JSM. Is there a plan for a dedicated CSM filter, or will this fall under a general “Service Collection”?
Compatibility: Will apps need to explicitly define compatibility for CSM vs. JSM? If an app supports both, will it be treated as a cross-platform app?
Development Strategy: Given the current state of JSM apps, is Atlassian’s recommendation to extend existing JSM apps to support CSM, or to build separate, standalone solutions for CSM (even if the functionality overlaps)?
3. Functional Parity & Extension Points
In our view, the “minimum viable plan” should be to provide CSM with the equivalent extension points we currently utilize in JSM.
Core Views: We need the ability to display modules on the Portal, Request Details view, Request Page, Queues, and the Agent view (Issue/Work Item). I have noticed that context issues seem to work correctly for the Agent view, which is a good start.
Space CSM: We specifically need the ability to hook into the Reports view.
UI Modifications: Will the UI modifications for the create/issue view in CSM projects be launched in alignment with the plans for JSM (as referenced in ROADMAP-116)?
4. Customer Experience (CX) & Configuration
Pages: We would like to display Forge modules on Pages and, crucially, allow customers to configure our modules directly there (similar to how app macros work in Confluence).
Forms: Currently, it is not possible to select custom fields from Forge in Forms, whereas this is possible in JSM for Request Forms. Are there plans to bridge this gap?
API: Do you plan to expose an API to fetch these configurations and provide extension points on these screens?
5. Integrations
Regarding the planned integrations mentioned in the RFC: could you elaborate on the scope and level of these integrations? This sounds like a feature that could potentially cannibalize existing integration solutions on the Marketplace. Understanding the boundaries of native integrations versus what is left for vendors is vital for our business planning.
