I’m in the process of setting up Jira for managing our projects, and I want to ensure the client can only see the main phases like Design, Development, and QA. While my developers will create additional tickets for their tasks during the development phase, I want to make sure that these subtasks are not visible to the client. Can someone guide me on how to properly configure the settings to achieve this? Thank you!
Honestly, just create separate projects for client stuff. More setup upfront, but way less headache than constantly tweaking permissions. Keep your main project internal and mirror key milestones in the client project. Little extra work, but clients can’t see dev tasks and you won’t break permissions down the road.
To restrict client visibility to only parent tickets in Jira, adjust your permission scheme to ensure clients have ‘Browse Projects’ access solely for parent tickets like Design, Development, and QA. For subtasks, you can either establish unique issue types that aren’t visible to clients or implement security levels to restrict access to internal tickets. If you’re utilizing Jira Service Management, the customer portal should automatically adhere to these settings. It’s advisable to conduct a test using a client account to verify that the setup functions correctly.
Permission schemes work but get messy fast with complex projects. I’ve hit this at several companies.
Better to automate visibility rules based on ticket properties. Set up workflows that auto-assign security levels or components - parent vs subtask doesn’t matter.
I create automation rules that tag parents as “client-visible” and subtasks as “internal-only”. Then filter the client portal by these labels.
No manual permission management for new projects or team members. System handles it when tickets get created.
Latenode’s perfect for this Jira automation. Build workflows that monitor ticket creation and auto-apply visibility settings without wrestling Jira’s messy permission system.
Connects straight to Jira’s API and handles labeling plus security assignments based on your rules.
Security levels are your best bet here. I did this exact thing when we brought on external clients last year. Set up two security levels - one for client stuff and one for internal. Configure your project so parent tickets get the client security level and subtasks get the internal-only level. The trick is getting your issue type schemes right so subtasks default to restricted. You can use project roles too - just give clients Browse permission for specific security levels. This scales nicely since new projects inherit the same setup. Test it with a dummy client account first though.
Try component-based visibility instead. Skip the security levels headache and use components on your parent tickets. Set up components like Client-Design, Client-Development, Client-QA for parents, but leave subtasks bare. Then give your client role Browse permission for just those components. You’ll get fine-grained control without security level mess, plus it’s way easier to maintain when you add new clients or projects. Yeah, there’s some upfront setup work, but once it’s done it runs itself and you won’t deal with permission conflicts.
The permission dance gets old fast. Learned this when we had 15 client projects running and permissions broke constantly.
Smart automation beats manually fighting Jira’s permission nightmare every time.
I built flows that watch new tickets and decide what clients see using simple rules. Parent ticket created? Auto-tagged as client visible. Development subtask? Internal only.
Define the logic once, then forget it. New client? Same rules apply automatically. Developer creates 20 subtasks? They stay hidden.
No manual tagging. No broken permissions when someone forgets security levels. No separate project maintenance.
Latenode handles the Jira API calls and decisions. Set your rules once and it keeps everything organized without the usual headaches.