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

[James Morris]

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 

[Ste Wright · Accepted solution]

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

[James Morris]

Thanks for your speedy response @Ste Wright - 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.
 

[Matthias Gaiser _K15t_]

@James Morris, in addition to what @Ste Wright 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.