robotsnoindex
descriptionGet the details on how access and permissions are defined in next-gen service desks, and what each permission allows people to do.
robotsnoindex

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

Three main settings determine a person's permissions in your next-gen service desk:

  1. Their product access.

  2. The service desk's internal access level.

  3. Their role in the service desk.

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.

Product access

For next-gen service desks, a person needs product access to Jira Service Desk to:

  • Become an agent of your next-gen service desk.

  • Create and administer their own next-gen service desks.

Site admins can grant users product access in their site administration settings. Learn more about updating product access.

Internal access levels

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

Next-gen service desks have two, simple internal access levels:

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

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

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

Your service desk’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.

When you add someone to a role, remember that they also inherit the role given by your service desk’s internal access level:

  • In Open projects, everyone with internal access to your Jira site is given the default Agent role. Only people with both the Agent role and product access to Jira Service Desk can communicate with customers and resolve requests.

  • In Private projects, only Jira admins and people you add to the project have a role.

Next-gen service desk permissions

Here’s a list of the permissions you can grant to define roles in your next-gen service desk. 

Add attachments

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

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone with internal access to your Jira site.

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.

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone with internal access to your Jira site.

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 desk portal.

Who can communicate with customers?

If you grant a role any of the permissions that appear under the Work on service desk requests set, anyone with that role can communicate with your service desk customers.

Add or remove issue watchers

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

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

Administer the service desk

This permission allows people access to your service desk’s settings. They can:

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

  • configure request types, their fields, and their workflows

  • make changes to the customer 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 desk and its customer requests outright

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

Assign any request

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

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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

What about the “assignable user” permission?

In classic service desks, Jira admins can control who can be assigned a request using permission schemes. In next-gen service desks, we’ve simplified our permissions sets. If you grant a role any of the permissions that appear under the Work on service desk requests set, anyone with that role can be assigned requests in the service desk.

Create requests internally

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

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone with internal access to your Jira site.

For some organizations, this creates a quick way for internal collaborators to raise requests in your service desk 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 desk’s portal even to internal customers. We also recommend service desk agents use the customer 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 Core. 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

None of these permissions require product access to Jira Service Desk. You may grant them to anyone with internal access to your Jira site.

Delete any attachment

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

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk’s requests. It’s a bit of a super power.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk’s requests

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk.

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone with internal access to your Jira site.

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 desk.

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone with internal access to your Jira site.

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 desk’s requests.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

Typically, people who actively work and log time in your service desk 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 desk’s requests.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk’s requests.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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).

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk’s requests.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk’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 customer 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.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk.

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone with internal access to your Jira site.

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 desk’s requests.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

Typically, people who actively work and log time in your service desk 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 desk to one another, or to issues and requests in other projects or service desks on your site. To view the link properly, they need the same permission in the target project or service desk.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

Log work on any request

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

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk.

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

Any of these permissions require product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 desk. This permission does not give teams using Jira Software the ability to transition, edit, or communicate with customers on your service desk requests.

This permission requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

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 Desk 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 Desk 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 desk’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 desk’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 requires product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

This permission is a combination of the Transition IssuesResolve Issues, and Close Issues permissions in classic projects.

View watchers

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

This permission doesn’t product access to Jira Service Desk. You may grant this permission to anyone logged in to your Jira site.

Work on service desk 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 desk customers.

Any of these permissions require product access to Jira Service Desk. Learn more about giving people access to your Atlassian products.

Last modified on Jun 9, 2020