# Limit permissions of suppliers
### Security – limit permissions for suppliers (or other specific groups)
Agile promotes transparency and collaboration with suppliers.
The default approach when working with suppliers in a program is to provide them visibility over the program.
In some cases, this approach is not feasible for compliance or legal reasons.
Sometimes, we want to limit the permissions and visibility a supplier has in a program.
This page explains how we can configure this in *Ativo Agile Programs for Jira*.
### Example
Let’s assume the following example.
A program, called ‘*Program Blue*‘, has its own set of features (epics).
This program has following teams:
* Team Lion
* Team Horse
* Team Owl
* Team Rabbit
Each team works with Jira, and has its own project in Jira to plan stories. (It is also possible for teams to share a Jira project).
A supplier, called ‘*supplier X*‘ is also contributing to the program.
### Approach
We want to include the deliverables from the supplier in our program plan.
We also want to give the supplier access to Jira, but without providing visibility on the features of the program, or on the stories of the other teams.
*Ativo Agile Programs for Jira* respects the project permissions of Jira. Users will not see more features or stories via the Ativo plugin than they are allowed to see.
We can hence limit the visibility of a supplier via the *Browse Projects* permission setting of each Jira project in the program. Regular members of the program will then be able to see the features and stories in the project. Members working for *Supplier X* will only be able to see the stories in the supplier Jira project.
More information about *Jira Project Permissions* can be found [here](https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/).
### Backup
Before changing the Jira configuration, make sure you have a recent and tested backup of Jira. More information [here](https://confluence.atlassian.com/adminjiraserver/backing-up-data-938847673.html).
### Configuration of groups
Jira promotes the use of *roles* because it is then easy and flexible for *Project Administrators* to add persons to their *Jira project*.
In this case, every member of the program needs to have *browse project permissions* to each project in the program. To accomplish this, it is probably easier to work with groups.
We start by creating two groups. (*Skip this step if you already created user groups in Jira.*)
First, we will create a group with all the regular members of the program (excluding members from *Supplier X*):
Repeat the above step to create a group with all the members working for *supplier X* who need Jira access.
### Setting the permission schemes
We will create two permission schemes. (*Skip this step if you already created permission schemes in Jira.*)
One scheme sets the permissions of all projects where all regular (non-supplier) members have access to:
* Jira feature list project
* Team Lion project
* Team Rabbit project
* Team Owl project
* Team Horse project
To create the scheme:
* As a Jira administrator, go to *Administration* > *Issues* > ***Permission schemes***
* Click on *Add permission scheme*, or on ***Copy*** to create a new scheme based on an existing one*.*
* Click on ***Remove*** next to ***Browse projects*** . Reduce the permissions so that *Supplier X* members don’t have access (**Be cautious!** This could have side-effects later where other eligible persons loose access to the project.)
* Click on ***Edit*** next to ***Browse projects.*** Grant permission to the *ProgramBlue* group, and to other groups and roles that need access to the projects of the program.\
Repeat the above steps to create a *Supplier X permission scheme*. Add the *SupplierX* group, the *ProgramBlue group* and any other group or role that needs visibility on the plan of *Supplier X*.
### Apply the permission schemes
Now that we’ve created the permission schemes, we can apply them on the relevant projects. Careful, this is the moment persons will loose access if we forgot to include them in the groups. Communicate upfront you are doing this change.
We will first apply the *ProgramBlue Permission Scheme* to following projects:
* Program blue feature list
* Team Lion
* Team Rabbit
* Team Owl
* Team Horse
To apply a permission scheme to a project:
* As a Jira administrator, go to *Projects* > *View all projects* and open the Jira project (e.g. the project of *Team Lion*)
* Click on ***Project Settings** > **Permissions***
* Click on ***Actions*** > ***Use a different scheme***
* Select the Permission scheme and click on ***Associate***\
Repeat this step to associate all projects in the program with the *ProgramBlue Permission Scheme*.
Then repeat this step to link the project of *Supplier X* to the *Supplier X Permission Scheme.*
### Program configuration
As a *Ativo Program Admin*, update the program configuration of *Program Blue* to also include *Supplier X* as a team.
* Go to *Programs* > *Settings* > ***Teams*** to create the *Supplier X* team.
* Select *Program Blue* program in the left navigation bar.
* Go to Programs > Settings > **Program** and add *Supplier X* as a team in the program.\
More information on the configuration of a program, period and team can be found [here](https://ativo.io/docs/setup/).
### Test the access for normal program members
Regular members of the program should still be able to see all projects and tickets in the program. They should also be able to see the program board and progress planning in *Ativo Programs*.
### Test the access for supplier members
Log in as a member of *Supplier X*.
Members of *Supplier X* will not be able to see the projects in the program. Go to ***Projects*** > ***Browse projects*** to verify that they only see the *Supplier X* project.
Iterate if needed on the permissions of other projects.
Members of *Supplier X* will not be able to see the features and stories on the program board. They should only see the names of the programs and periods. Go to **Programs** , select a program and period, and click on plan.
A *permission denied* error or *fetching issues on url failed (400)* error should be visible:
### Update tickets as supplier member
Members of *Supplier X* can edit the tickets of the *Supplier X* project. They can plan and update a story in a sprint.
Changes to sprint planning will be reflected on the program board.
Members of *Supplier X* can also set a RAG (Red / Amber / Green flag) and risk/issue description on a story:
* As a member of *Supplier X*, locate the story you want to update on the backlog.
* Click on ***Edit***
* Select the ***Program*** tab
* Update the ***RAG*** and ***RAG comment*** sections.\
Changes to *RAG* and *RAG comments* will be reflected on the program board.
### Conclusion
The agile manifesto promotes transparency and a good collaboration with suppliers.
It is nevertheless possible to provide Jira access to a supplier and include his deliverables on an Ativo Program Board, while **limiting** the **visibility** on other projects and on the program board.
As a Jira administrator:
* Ensure a **backup** is created
* Isolate the regular program members and members of a supplier in different **groups**
* Create **permissions schemes** for the regular Jira projects and a separate permissions scheme for the project of the supplier
* Apply the permission schemes to the **projects**
* **Validate** the result