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:

1. Which approach have you found more sustainable as your organization scaled?

2. If you went with the Single Project + ILS route, what safeguards or automations did you put in place to prevent accidental data exposure?

3. 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!

[John Funk · Accepted solution]

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. 

[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.