Service Desk Customer vs. Service Space Customer Disconnect?

[Katie Lee]

Is anyone experiencing issues all of a sudden due to the disconnect between the global mail handler looking for a specific system role: Service Desk Customer but the new "Service Space" architecture, the role was renamed this role to Service Space Customer?

We're experiencing some funky issues recently and trying to identify the root source. Thinking it could be because at the Space level, it's looking at the new role but at the global settings level, it's looking for the old one. 

[Gunjan Kumar]

Hi @Katie Lee 

I think the issue is coming from a role mismatch after the move to Service Spaces. Earlier, JSM used the role “Service Desk Customer”, but with Service Spaces Atlassian has shifted to a different customer model at the space level. The problem is that global configurations like the mail handler may still be looking for the old role, while the Service Space is using the new one.

Because of that disconnect, users might not be recognised properly as customers, which can cause odd behaviour with email requests and permissions. So the “funky issues” we’re seeing are likely due to this mismatch between global settings and the new Service Space setup.

[Katie Lee]

Thank you, @Gunjan Kumar

Have you run into a similar issue? If so, how have you fixed the issue or any ideas on how to resolve?

[Arkadiusz Wroblewski]

Hello @Katie Lee 

Atlassian has renamed a lot of the product wording to service space, but the underlying permission/security model still uses the older Service Desk Customer naming in the docs and configuration model. So this looks like a terminology change in the UI than an actual role mismatch in the backend.

Because of that, I would focus less on the old/new label difference and more on whether anything changed in your permission scheme, customer permissions, or email channel behavior recently. If this started suddenly, I would also not rule out a product-side regression.