Hello, I just wonder if it’s a good practice to create servicedesk tickets and epic/stories/tasks on the same Jira project. Here is my case : * I have a single JSM project (let’s call it PROJECT_A) for all my customers. I would like to split PROJECT_A into 1 project by customer (let’s call them CUST_A, CUST_B, etc.) * I already have Jira Software project called CUST_A, CUST_B with stories and tasks that I share with my teammate only (not the customer) By defining the right accesses and permissions, is it a good practice to gather my customers' tickets and my teammates' tasks in the same project (one per customer)? Or is it better to separate them and therefore have two projects (one Jira SM and one Jira Software) per customer? Sincerely,

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Merge Jira software and Jira SM projects

Adrien Smondack

Hello,

I just wonder if it’s a good practice to create servicedesk tickets and epic/stories/tasks on the same Jira project.

Here is my case :

I have a single JSM project (let’s call it PROJECT_A) for all my customers. I would like to split PROJECT_A into 1 project by customer (let’s call them CUST_A, CUST_B, etc.)
I already have Jira Software project called CUST_A, CUST_B with stories and tasks that I share with my teammate only (not the customer)

By defining the right accesses and permissions, is it a good practice to gather my customers' tickets and my teammates' tasks in the same project (one per customer)? Or is it better to separate them and therefore have two projects (one Jira SM and one Jira Software) per customer?

Sincerely,

Accepted answers

Jehan Bhathena

Hi @Adrien Smondack ,

Assuming that the internal projects have development tasks that you don't want customers seeing, would suggest creating a different project since the Browse Project permission is common across project and cant be filtered down to issue types, unless you use Issue Security schemes, the 1 Project for Customer and Team might not be feasible.

For the other point where you mentioned splitting Project 1 into CustA and CustB, perhaps you can achieve this level of tracking by creating a component or custom field specific to each customer and track the requests based on that?

Perhaps you can share a little more insight into your use case? What is the end goal you're trying to achieve, maybe that can help others with more information about what might be the better way ahead.

All comments

Jehan Bhathena

Hi @Adrien Smondack ,

Adrien Smondack

Hello @Jehan Bhathena ,

Thanks for your response.

My aim is to separate my customers into dedicated projects, with two main objectives:
- to limit information leaks from one customer to another
- better meet their requirements without impacting others

My Atlassian cloud environment includes Jira SM, Jira Software and Confluence. We use Jira Software for simple day-to-day internal task management, with no need for customers to have access to it.

Unless it's recommended for a particular reason I hadn't thought of, I'd like to avoid having to manage two projects per customer that my teammates have to juggle with.

Make a Service Management project with distinct schemes for JSM and JSoftware issues would do the job, I think. Adding security level is in fact a must-have. With these insights, do you think it's still necessary to have two projects per customer? And if so, why?

Best regards,

Jehan Bhathena

Hi @Adrien Smondack ,

Thanks for the insights.

For the point "to limit information leaks from one customer to another", this alone justifies the reason to create 2 different projects in my opinion. Given the need of strict confidentiality around customer related information, having 2 projects would be much better.

To avoid the Administrative overhead in this use case I would suggest creating a common permission scheme, that allows only a certain "Role" to access that project instead of the common Jira-software group. This way you have total control over who gets added to the project, and when. While this is just one approach you can perform multiple other ways as well.

Few links that show how to manage Internal and External users in the same site:

* https://community.atlassian.com/t5/Jira-Software-questions/JIRA-Software-project-permission-restrict-user-access-to-one/qaq-p/779572#M265522

* https://community.atlassian.com/t5/New-to-Jira-articles/How-to-give-a-user-read-only-access-to-a-single-project-and/ba-p/1010143

Hope this helps.

Adrien Smondack

Thank you for your replies.

I think then I’ll make 2 projects for each customers.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software-cloud

jira-service-management-cloud