Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,461,153
Community Members
 
Community Events
176
Community Groups

What's the recommended method to include Partner Team(s) & restrict access within a Jira Instance

Seeking advise on best methods to include/restrict access to/within a Jira Instance for Partner/Client Team(s) 

We currently have ...
User Groups in Confluence + Jira + Slack for each Client + Partner  + internal Team 
visualise work for/with Partner Teams via a Custom Field "Team"
visualise work for/with Clients via Customer Field "Client" 

Partner teams work with 1:n Client Team(s) + our internal team 

1 answer

1 accepted

1 vote
Answer accepted

Hi @James Morris 

In general, I'd advise...

  • Platform Access: Handle using separate Groups, with no relationship to data access. This means being granted access to Jira provides either no Project access, or access to public Projects only.
  • Group Access: This is used for Project access, even if using Roles. Whilst not ideal administratively, I do find separate Permission Schemes where Groups are used for Browse Projects can be more secure in this scenario.
  • Project Type: Utilise Company-managed over Team-managed in Jira, as permissions can be more definitive and centrally managed.

There are then two main options for data management in Jira...

 


Option 1 - Project Permissions

This option works well if there is a definitive split between Projects - eg. all of a Partner/Client's work is in one Jira Project/Confluence Space.

In this instance I would...

  • Create a Permission Scheme, granting Project access based on their Group membership
  • Manage all other Permissions via Project Roles

See more about Project Permissions on this page.

 


Option 2 - Issue Security

If the above option is too limiting, the alternative is to use Issue Security - allowing for more granular Issue visibility management.

Then, I would...

  • Manage Project access using Groups - but, Project Roles could be used in the Permission Scheme - as Issue access will manage visibility
  • Create an Issue Security Scheme per Project - and...
    • Set default visibility to the internal team only
    • Set relevant security levels for Partners/Clients
      • There might have to be a fair few of these though, if different combinations of Partners/Clients might need to view an Issue.
  • Assign Issue Security levels per Issue depending on visibility needs
    • Consider using Automation for this where possible - for example, if Epic A is visible to Client 1, and all children should also be visible due to this, use Automation to set the appropriate Security Level at creation, or when Epic Link is updated.

See more about Issue Security on this page.

 


There isn't as granular permissions for Confluence if you need this also - permissions are all managed at a Space level and cannot be limited like above. I would consider though...

  • Not providing Space Admin permissions to non-internal team members.
  • Using Page Restrictions - as view access is inherited, you could...
    • Group all public pages under one main page tree
    • Create a restricted page tree, which would auto-hide pages from the non-internal team. Create new pages here first
    • Either move pages to the public tree when required, or create more page-trees to show different sets of pages to different Clients/Partners

 


Let us know what you think :)

Ste

Thanks for your speedy response @Stephen Wright _Elabor8_ - greatly appreciated

Prob going to stick with the single Jira Project to keep it simple & open and manage access via user group privs if needed later. Ideally we should be working with Trusted partners or internal colleagues so the user group permissions should work fine for us.
 

@James Morris, in addition to what @Stephen Wright _Elabor8_ already elaborated, you could also go a step further and synchronize issues between your instance and your partner's instance. This way you don't need to deal with permissions/groups/users in your instance but rather with the configuration of your desired issue sync app.

Let me know if I should elaborate this option in more detail.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events