Best Practices: Issue-Level Security vs. Multiple Projects for Customer Visibility? Hi everyone, I'm a Jira Admin looking for some advice on best practices regarding project structure and managing customer visibility. We are currently debating the best approach to restrict our customers from seeing internal issues and comments, while still keeping our engineering and support teams perfectly aligned. We are weighing two main approaches and I would love to hear how others have successfully scaled this in their organizations. Approach 1: Single Project with Issue-Level Security (ILS) * The Idea: Keep everything in one project and use Issue Security Schemes to restrict visibility, ensuring customers only see the issues explicitly meant for them. * Pros: A single source of truth for the team. There is no need to jump between projects, no need to sync fields or statuses, and reporting is much easier. * Cons: High risk of accidental exposure. If a team member forgets to set the correct security level (or if a default is misconfigured), internal data could be exposed to a customer. Issue security can also become complex to manage as the team grows. Approach 2: Multiple Projects (Internal vs. Customer-Facing) * The Idea: Create a dedicated customer-facing project (e.g., a Jira Service Management portal) and a separate internal project for our engineering/product teams. * Pros: Very clean separation of data and permissions. There is virtually zero risk of a customer accidentally seeing an internal issue or internal commentary. * Cons: Requires linking issues between the two projects and setting up Automation for Jira to sync comments, attachments, and status transitions. It also introduces the administrative overhead of maintaining multiple projects and workflows. My Questions for the Community: * Which approach have you found more sustainable as your organization scaled? * If you went with the Single Project + ILS route, what safeguards or automations did you put in place to prevent accidental data exposure? * If you went with the Multiple Projects route, how do you manage the overhead of syncing issues and keeping the internal/external teams aligned without creating a messy web of automations? Thanks in advance for your insights!

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; } } }

Best Practices: Issue-Level Security vs. Multiple Projects for Customer Visibility?

sucheta.godbole

Best Practices: Issue-Level Security vs. Multiple Projects for Customer Visibility?

Hi everyone,

I'm a Jira Admin looking for some advice on best practices regarding project structure and managing customer visibility.

We are currently debating the best approach to restrict our customers from seeing internal issues and comments, while still keeping our engineering and support teams perfectly aligned. We are weighing two main approaches and I would love to hear how others have successfully scaled this in their organizations.

Approach 1: Single Project with Issue-Level Security (ILS)

The Idea: Keep everything in one project and use Issue Security Schemes to restrict visibility, ensuring customers only see the issues explicitly meant for them.
Pros: A single source of truth for the team. There is no need to jump between projects, no need to sync fields or statuses, and reporting is much easier.
Cons: High risk of accidental exposure. If a team member forgets to set the correct security level (or if a default is misconfigured), internal data could be exposed to a customer. Issue security can also become complex to manage as the team grows.

Approach 2: Multiple Projects (Internal vs. Customer-Facing)

The Idea: Create a dedicated customer-facing project (e.g., a Jira Service Management portal) and a separate internal project for our engineering/product teams.
Pros: Very clean separation of data and permissions. There is virtually zero risk of a customer accidentally seeing an internal issue or internal commentary.
Cons: Requires linking issues between the two projects and setting up Automation for Jira to sync comments, attachments, and status transitions. It also introduces the administrative overhead of maintaining multiple projects and workflows.

My Questions for the Community:

Which approach have you found more sustainable as your organization scaled?
If you went with the Single Project + ILS route, what safeguards or automations did you put in place to prevent accidental data exposure?
If you went with the Multiple Projects route, how do you manage the overhead of syncing issues and keeping the internal/external teams aligned without creating a messy web of automations?

Thanks in advance for your insights!

Accepted answers

John Funk

Hi Sucheta,

Great question! So, there are a couple of factors to this - the number of work items/tickets that will be create in total in the project(s), and the amount of risk you are willing to take.

If it is absolutely critical that the people cannot see others work items and there are a lot of levels to have to juggle, then the risk is high and you should use multiple projects.

If only a few different security levels are needed and not a lot of tickets to be created, then I usually prefer the single project. Just be sure to use the most restrictive level as your default level and then modify the level manually or through automation as needed. Less risk this way.

All comments

John Funk

Hi Sucheta,

Great question! So, there are a couple of factors to this - the number of work items/tickets that will be create in total in the project(s), and the amount of risk you are willing to take.

If it is absolutely critical that the people cannot see others work items and there are a lot of levels to have to juggle, then the risk is high and you should use multiple projects.

sucheta.godbole

Thank you so much for your response @John Funk

Matthias Gaiser _K15t_

, I'd recommend it similar to

If you want to go down the multiple projects route and also want to include comments and attachments, I'd recommend using an actual syncing tool since there are still quite some limitations with attachments - and you need to maintain your own rulesets of automations.
But it's also fair to call me biased here, because I'm part of the team behind Backbone Work Sync, one of the syncing apps. With such an app, the complexity is not on your shoulders, but on the app.

Managing access to the information gets easier then, but you still need to have clear criteria when is some information shared with the other project. Ideally this is based on actual data you store in Jira anyways, e.g. when you have a custom field "customer" everything is synced with that customer's Jira project.
If one of your customers is also using Jira, you could even sync directly with their Jira instance.

If you want to take that route, feel free to reach out to us for further discussions.

Javier Pozuelo -Exalate-

Hi @sucheta_godbole I'm Exalate

If keeping customer information separated is really important, I would probably go with different projects: a Jira Service Management project for customers and a Jira Software project for the internal team. Issue level security can work, but there is always some risk if the wrong security level is applied.

If both projects are on the same Jira site, Jira Automation is a good place to start. You can create and link the internal issue, copy the main fields, and sync a few important status updates. If the setup grows and you need comments, attachments, custom fields, and statuses to stay in sync both ways, then something like Exalate could make that easier to manage and give you more control over what is shared.

John Funk

You are very welcome.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud