Overview of permissions in team-managed service projects

This page describes permissions for internal service project users. For information about customers, read about customer permissions.

Two main settings determine a person's permissions in your team-managed service project:

1. The service project's internal access level.

2. Their role in the service project.

Site admins control who's licensed to use the Atlassian products their organization is subscribed to. Read more about managing users and application access across your Atlassian site.

Internal access levels

The service project's internal access level gives any logged in Jira user a certain role in your service project.

Team-managed service projects have two, simple internal access levels:

• Open. When a service project is open, anyone who logs into your Jira site (not the portal) can view and add internal notes to your project’s customer requests. With this access level, Jira Service Management gives anyone who logs into your Jira site the Agent role in your service project. Only people with the Agent role and product access to Jira Service Management can communicate with customers and resolve requests.

• Private. When a service project is private, only Jira admins and people added to the service project can see it or its requests in search results.

Jira administrators (anyone with the Administer Jira global permission) always have access to your service project's settings.

Your service project's access level sets general permissions for people with internal access to you Jira site. You can give specific access or additional permissions to individual people by creating your own roles. Read more about roles.

Team-managed service project permissions

Here’s a list of the permissions you can grant to define roles in your team-managed service project. 

Add attachments

This permission allows people to attach files to any request in your service project. Your Jira admin may limit what you can attach and how big your files can be.

Typically, any team member or collaborator needs this permission to help describe their work. Learn more about attaching files and screenshots to issues.

Add internal notes

This permission allows people to comment on any request in your project.

Typically, any team member or collaborator needs this permission to communicate internally on customer requests. Internal notes do not display to customers using your service project's portal.

Add or remove issue watchers

This permission allows people to add or remove people from a request’s watch list.

Administer the service project

This permission allows people access to your service project's settings. They can:

• edit other people’s internal access to the service project

• configure request types, their fields, and their workflows

• make changes to the portal

• manage customer notifications

• change knowledge base settings

• set up automation rules

• manage service level agreements

• enable or disable customer satisfaction surveys

• delete the service project and its customer requests outright

Assign any request

This permission allows people to change the value of the Assignee field on any of your service project's requests.

This permission allows team members to hand over tasks at different stages of the work.

Create requests internally

This permission allows people logged in to your Jira site internally to create requests in your service project. Usually, this happens via the + Create button in the navigation bar.

For some organizations, this creates a quick way for internal collaborators to raise requests in your service project anywhere from inside Jira. But, we don’t recommend this. Requests raised internally may cause unexpected behavior, including incorrect data entry for customer fields. We encourage internal service teams to promote their service project's portal even to internal customers. We also recommend service agents use the portal to raise a request on behalf of a customer, rather than Jira’s internal create button. This helps with proper tracking, sorting, and filtering for customer requests' Reporter field. Learn more about how to raise requests.

Collaborate on requests (a set of permissions)

This set of permissions is typically granted to team members who don’t play a central role in your project. Your team may involve them in answering questions to help fulfill a request. Usually, these are developers using Jira Software or business administrators using Jira Work Management. Depending on your organization, you might give these permissions to developers, technical writers, consultants, or other supporting roles.

Granting this permission set grants the following bundled permissions:

• Add attachments

• Add comments

• Edit their own comments

• Delete their own attachments

• Delete their own comments

You may grant these permissions to anyone with log in access to your Jira site. For example, if you have multiple Jira products on the same cloud site, a Jira Service Management agent can be given this set of permissions and collaborate on issues in Jira Software.

Delete any attachment

This permission allows people to remove any attachments added by anyone on any of your service project's requests.

While some teams may reserve this permission for management roles, open organizations can benefit from granting this power to autonomous team members. For example, as work progress, technical schematics or other diagrams may change. It might be beneficial for team members to keep attachments up to date, even if they aren’t the owner of the original attachment.

Delete any internal note

This permission allows people to remove any internal note added by anyone on any of your service project's requests. It’s a bit of a super power.

For traceability and historical investigations, we recommend preserving all internal notes, replies to customers, and customer comments. They can help you trace how a request was resolved, or how an interaction could be improved in the future. For that reason, you may reserve this permission for team leaders, human resource managers, or other management roles.

Delete any request

This permission allows people to delete any request in your project, including its associated field data, internal notes, customer replies, and work log entries.

This permission is typically reserved for team leaders or project management roles. We don’t recommend deleting requests as a practice. Changing a request's status to a done-category status is a much better way of clearing up unneeded requests. Changing a request’s status notifies the request’s reporter, assignee, and watchers of the action your team has taken on the task.

Delete any work log entry

This permission allows people to remove any work log entry added by anyone on any of your service project's requests

Typically, removing other people’s work log entries is a permission reserved for team leaders or other management roles.

Delete their own attachments

This permission allows people to remove any file or image they attached to any request in your service project.

Typically, anyone who can attach files to a request (by having the Add attachments permission) should be able to remove their own attachments. This practice can help clarify work where many versions of a file or image are uploaded throughout the course of resolving a request. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout a request’s lifecycle.

Delete their own internal notes

This permission allows people to remove any internal notes they’ve added to any request in your service project.

Typically, anyone who can leave internal notes on a request (by having the Add internal notes permission) should be able to remove their own internal notes. This practice can help clarify work if people leave erroneous or inaccurate notes. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout a request’s lifecycle.

Delete their own work log entries

This permission allows people to remove the time they logged, the time they estimated as remaining, and the description of any work log entry they added to any of your service project's requests.

Typically, people who actively work and log time in your service project need to delete their own work logs in case of data entry errors.

Edit any internal note

This permission allows people to alter the content of any internal note added by anyone on any of your service project's requests.

Open organizations encourage teams to edit each other’s internal notes to correct minor problems like spelling errors or broken links, and generally keep the communication stream clean. Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Edit any due date

This permission allows people to change the value of the default Due date field on any of your service project's requests.

Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Edit any request

This permission allows people to alter the summary and description, and change the value of fields that aren’t restricted by another permission (like the Assign requests or Edit reporters permissions).

Open organizations encourage teams to keep each other’s work up to date by adjusting fields when viewing requests throughout the course of their work. The ability to clarify descriptions and update fields is especially handy for team members who may review requests during shared rituals like standup meetings, planning meetings, or queue grooming sessions. Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Edit any work log entry

This permission allows people to alter the time logged, time remaining, and description of any work log entry added by anyone on any of your service project's requests.

Typically, adjusting other people’s work log entries is a permission reserved for team leaders or other management roles.

Edit reporters

This permission allows people to change the value of the default Reporter field on any of your service project's requests. The Reporter field is automatically set to the request’s creator at the time the request is raised. Usually, this is the customer who submits a request through your portal. The Reporter field may be set manually when raising a request on behalf of a customer. Learn more about how to raise requests on behalf of a customer.

Edit their own internal notes

This permission allows people to alter the content of any internal notes they’ve added to any request in your service project.

Typically, anyone who can leave notes on a request (by having the Add internal notes permission) should be able to adjust their own notes and correct minor problems like spelling errors or broken links. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout a request’s lifecycle.

Edit their own work log entries

This permission allows people to alter the time they logged, the time they estimated as remaining, and the description of any work log entry they added to any of your service project's requests.

Typically, people who actively work and log time in your service project will need to adjust their own work logs in case of data entry errors or changes to the work’s scope or requirements.

Link any issue

This permission allows people to link requests in your service project to one another, or to issues and requests in other projects on your site. To view the link properly, they need the same permission in the target project.

Log work on any request

This permission allows people to interact with the time tracking field on any of your service project's requests.

This permission allows people to create a work log entry, where they can indicate the time spent and time remaining to fulfill the request, including a brief description of the work they did along the way.

Manage project requests (a set of permissions)

This set of permissions is typically granted to team leaders, managers, and other roles that generally oversee the service project.

Granting this permission also grants the following bundled permissions:

• Add or remove request watchers

• Delete any attachment

• Delete any comment

• Edit any due date

• Edit any internal note

• Edit any work log entry

• Edit reporters

• Delete any request

• Delete any work log entry

Manage requests in Jira Software project sprints

This permission allows people to create, start, and complete sprints in Jira Software projects that include requests from your service project. This permission does not give teams using Jira Software the ability to transition, edit, or communicate with customers on your service project requests.

Sprints are a concept from agile methodology, specifically a way of working called Scrum. Typically, sprints are managed by team leaders or designated Scrum masters. Some Jira Software teams working in a Scrum way include Jira Service Management customer requests on their sprint boards to track their progress in their own team’s workspace. For example, organizations that create software may have a Jira Service Management project that collects bug reports from customers. An internal development team using Jira Software may create a filter to include these bug reports in their Scrum development boards, without having to recreate them as issues in their Jira Software project. These types of teams need permission to start and complete sprints that include your service project's requests.

Transition any request

This permission allows people to view any request’s underlying workflow and update the status of any of your service project's requests. They can move any issue through the workflow, triggering any workflow or automation rules that may be associated with the transition along the way. This permission may be overridden by the Restrict who can move a request workflow rule. Learn more about workflow rules.

This permission is a combination of the Transition Issues, Resolve Issues, and Close Issues permissions in company-managed projects.

View watchers

This permission allows people to see who’s watching any request in your service project.

You may grant this permission to anyone logged in to your Jira site.

Work on service project requests (a set of permissions)

This set of permissions is typically granted to service agents, service team managers, and others directly working to resolve your customers' requests. Typically, these permissions are meant for who you might consider members of the core team.

Granting this permission also grants the following bundled permissions:

• Assign any request

• Delete their own work log entries

• Edit any request

• Edit their own work log entries

• Link any request

• Log work on any request

• Transition any request

If you grant a role any of these permissions, anyone with that role can communicate with your service project's customers.