Best practices for sharing JSM and Jira reports with external customers

[J_P_ Mehlhaff]

Hello Atlassian Community,

We are looking for advice on the best way to provide external customers access to view and collaborate on issues in our Jira Service Management (JSM) instance.

Our goal is to allow customers to log tickets in a JSM portal, while still being able to link related issues to internal Jira Software projects for escalation and tracking with our development teams.

Some specific questions:

• What is the recommended approach for sharing JSM tickets and related Jira issues with external users?
• We were considering creating a Confluence space and embedding JSM reports/charts using Jira macros. Would external Confluence users be able to view and comment on the embedded Jira content?
• Has anyone set up a similar external collaboration process between JSM and Jira Software? What worked well or posed challenges?
• Any other tips or best practices for providing external customer access to Jira while maintaining separation of internal issues?

We want to balance open collaboration with customers and protecting internal project data. Hoping to learn from the community's experience with similar external Jira access scenarios.

Appreciate any guidance! Let me know if any clarification would help.

[Brant Schroeder]

@J_P_ Mehlhaff We currently do that and use automation to post information from the project to the customer.  See answers below:

Some specific questions:

• What is the recommended approach for sharing JSM tickets and related Jira issues with external users? Just use JSM issues to communicate with the customer.  You can sync comments between tickets using automation.
• We were considering creating a Confluence space and embedding JSM reports/charts using Jira macros. Would external Confluence users be able to view and comment on the embedded Jira content? In order to view issues in confluence you need to have access to them as a licensed user.  You can also not comment on issues in confluence. 
• Has anyone set up a similar external collaboration process between JSM and Jira Software? What worked well or posed challenges?  Sync works well and Atlassian even has examples on it.  https://www.atlassian.com/software/jira/service-management/product-guide/tips-and-tricks/jira-service-management-and-jira-software#overview
• Any other tips or best practices for providing external customer access to Jira while maintaining separation of internal issues? See link above.

[J_P_ Mehlhaff]

Hey @Brant Schroeder thank you for the response, it's very helpful! I think you're right that JSM and automation is the simplest approach. 

• Do you ever need to share a report with the customer based on their issues, such as open issues grouped by status or SLA adherence? If so, how do you go about that, considering the lack of reporting ability in JSM within the customer's UI?
• Do you have any best practices on automation or any rules that are must-haves? Syncing comments seems like a good-place to start, but have you run into any challenges when you're linking 1 JSM issue to many Jira issues?

[Brant Schroeder]

@J_P_ Mehlhaff Great questions.

• Do you ever need to share a report with the customer based on their issues, such as open issues grouped by status or SLA adherence? If so, how do you go about that, considering the lack of reporting ability in JSM within the customer's UI? If we have reporting like this that we have to provide we do it manually since the user would have to have access to the application and issues to see them.  I would recommend trying to meet all the reporting needs on a single dashboard (minus SLA)  You can then share this in a meeting on the screen or easily print it off and email it.  
• Do you have any best practices on automation or any rules that are must-haves? Syncing comments seems like a good-place to start, but have you run into any challenges when you're linking 1 JSM issue to many Jira issues? No best practices for automation as each situation / business process is usually unique.  I actually try to limit the number of automations that we use to try and keep things simple.