Many limitations on Customer Service Management

[Christof Hurst]

Hi, 

I'm testing the new Customer Service Management for a Compliance portal but I face face many limitations.

I like the features that different portals (Customer Experiences) can be configured. When trying to add Assets to the form or even use them internally to set our internal Brand object, I face that no support for assets is included. Why? This is an essential feature to organize work. Even no prefilled fields, so there is nothing to identify.

Also the forms are another limited thing. Why aren't used the normal form feature which ist tested and included very well? 

AND NO AUTOMATION RULES???

Why always news things that work only half the way? Why always new from the scratch? Why always limited forks of well functioning things? The new CSM could be a good thing but actually it's not usable.

BR Christof

[Arkadiusz Wroblewski]

@Christof Hurst 

Christof  I feel this one. I checked what Atlassian currently documents for Customer Service Management, and the short version is: CSM is a new “experience layer” (customer experiences) and it’s not feature-parity with classic JSM portals yet. That’s why you’re seeing missing basics like Assets in forms, prefills/context, and the “why isn’t this just JSM Forms?” feeling.

Atlassian’s docs make it clear CSM is organized around customer experiences/customers/projects, it’s not just a skin over JSM. So you’re basically testing something that’s still scoped. It can be great for clean multi-portal experiences, but for compliance workflows (where Assets + automation = the glue), it’s currently hard to call it complete.

Practical reality right now: if Assets + automation are essential, keep the real process in classic JSM projects (where automation is fully supported), and only use the CSM “experience” front end where it genuinely helps otherwise you’ll spend your time designing around product gaps.

And yeah  if Atlassian wants CSM to be taken seriously for compliance/customer portals, Assets integration + real automation + form parity shouldn’t be “maybe later”. It’s baseline.

[Dwight Holman]

We explored CSM a few months back, and also felt underwhelmed. Despite CSM being built for the main use-case we wanted, JSM felt better (and more mature). To be expected given how much older it is. 

Both have strange restrictions and gaps that have (so far) discouraged us from using either product. Every org will have a different wishlist for Atlassian.

As far as I know the following gaps/limitations apply:

• They do not allow OPEN email access with restricted portal access. I think this is true for both CSM and JSM.
  See JSDCLOUD-6307
• Neither provide proper access control for KB content. e.g. content visible to selected organizations (or groups of organisations).
  See JSDCLOUD-8006
• They do not reply when the email handler cannot create or update an issue.
  See JSDCLOUD-818
• JSM can block email domains and addresses, but cannot block users from registering via the portal. CSM doesn't seem to do either. See JSDCLOUD-18003.
• When users log ticket via the portal, it shows related KB content, but does not show previous tickets logged by the user (or other users in the organisation). There is a feature to show similar issues to agents, but not customers.

Since exploring CSM we have been waiting for updates but not much seems to have changed. Maybe CSM is a low priority - it does not seem to be 'catching up' with JSM. The small number of CSM tickets in JAC suggest little traction with customers.

As of 20 Apr 2026 the work items counts in JAC:

• 91 for Customer Service Management
• 14,005 for Jira Service Management

@Christof Hurst - have you decided to use something else instead?

[Christof Hurst]

Hi @Dwight Holman ,

thanks for your experiences. As different portals within one project is our main goal, and at ther moment only the first portal ist necessary, I keep on CSM. I hope that basic features for normal usage are coming soon. 

Latest when the second portal is requested by customer, I will re-evaluate and make decisions.

The very basic thing is to determine from which portal the request is made.