Documentation forSolarWinds Service Desk

Roles & Permissions

Each user utilizing the SolarWinds Service Desk is assigned a role in order to identify their specific access within the application. Depending on the role assigned, you will be able to navigate to specific areas within your SWSD, in addition to being assigned permisions and/or restrictions. The permissions/restrictions provide an added level of control for the administrator to manage the users within your organization.

We first review the roles followed by how permissions and restrictions are used to ensure every user has access to only what is relevant to them and ensures confidentiality when needed.

You may select the link below to go directly to:

SWSD Role Types

There are 4 main role types:

  • Administrator (License required)

  • Service Agent User (License required)

  • Service Task User (Does not require a license)

  • Requester (Does not require a license)


This role exhibits the highest level of access to the application. All users assigned as administrators have complete access to all areas of the setup including the ability to delete items (such as assets, knowledge articles, incidents, etc.) unless restrictions have been placed on this specific user.

As an Administrator, you can grant Agent Roles specific permissions to:

Objects: audits, incidents, problems, reports, etc.

Setup areas (defined by menu blocks) including: account, user&groups, integrations, global setting, service desk setting, CMDB, discovery& assets, and labs.

By granting permissions to Agent Roles, you as the administrator can delegate on-going setup activities such as workflows, automation, or notification setup for specific agents.

This is a licensed role and will count against the number of licenses you purchased.

As an Administrator, you are the only role that can enable APIs within workflow processes on your SWSD (backend and frontend). To allow this, you must go through Token Based Authentication. For more on Token Authentication for API Integration, please click here.

Service Agent User

This role is allocated for technicians, giving them access to the system in order to work on incidents or manage assets.

In addition,

Notice the 4 options on the right:

  • View Users - View All Users index page with the ability to edit and filter the roles you wish to include in your view.
  • Clone Role - Allows you to create new roles while maintaining the same description and user license type of existing roles.
  • Restore to Default - IMPORTANT: when you elect to restore to default, this action CANNOT be undone.
  • Add Permissions -
    • Define the Action allowed such as: Manage, Read, Create etc
    • Define the Subject within objects and setup. This allows the Service Task User to have access to some/all the setup actions in the setup menu.

This is a licensed role and will count against the number of licenses you purchased.

Service Task User

Users in this role have access to the Service Portal, allowing them to submit tickets, requests and view knowledge base articles. This role is considered to be an "elevated requester", as these users will also have the means to be assigned tasks and provide approvals. From the service portal, service task users can manage their pending tasks and approvals from the "My Tasks Menu" as well as from their email.

Notice the 4 options on the right:

  • View Users
  • Clone Role
  • Restore to Default
  • Add Permissions

This is a non licensed role.


This role is for Service Portal access only. Users in this role can use the portal to submit Incidents, Service Requests and view knowledge base articles. Requesters can also have an ongoing correspondence using "My Requests" from the portal.

Notice the 4 options on the right:

  • View Users
  • Clone Role
  • Restore to Default
  • Add Permissions

This is a non licensed role.

Any individual with a Requester role can not be assigned any tasks and/or approvals.  If such individual must attend to tasks and/or approvals they must first be changed to a Service Task User role. 

While each role's out of the box visibility is beneficial, you can leverage permissions and restrictions to build custom roles as they align with your organizational needs. This can all be accomplished with click-drag-drop actions, and scoping based on your organizational attributes (such as site - department - category). Leveraging permissions and restrictions, you can scope roles on a granular level to silo user's accessibility and visibility to data.

Permissions and Restrictions

In your SWSD, permissions and restrictions allocated to a role denote and differentiate user groups and their access within the application.

For example: When assigning permissions for personas involved in the Change Lifecycle click here for best practices.

Roles should always be built from the top down with permissions granted and then by way of restrictions taken away per subject or scope.  Keep in mind, permissions and restrictions are dynamic and can be changed as necessary. 

You'll find several articles below that will guide you in this setup. In addition, there are  some great examples for building roles for departments other than IT, such as Facilities, Human Resources or even your Marketing team!

It is imperative to understand the following terms to better define the roles in your organization:

  • Users: Users can only be linked to a single Role at a time.

  • Roles: Describes license type and can include 1 or more permissions and restrictions.

  • Permissions/Restrictions:

    • Permissions: Determine the scope of what data users can access, how they can interact with the data and what actions they can take in the platform.

    • Restrictions: Help to silo and remove visibility to data while helping to limit actions for users.

  • Actions: All the available actions that can be given or restricted to users. The baseline actions include:

    • Create - create content

    • Read - consume data

    • Update - make changes to existing content

    • Delete - removal of data from the system

    • Manage - encompasses all actions

      *Please note: When Read or Manage restrictions are assigned to a role, selecting certain restrictions, will removea43 visibility of specific sections, e.g. removal of the Asset modules from view of specific Users.

  • Subject: This encompasses the module of the platform that a permission or restriction is allocated to. Subject can range from:

    • Areas in the service desk (e.g. Incidents, Problems, Changes, etc.)

    • Inventory (e.g. Computers, Other Assets, etc.)

    • Procurement and more.

  • Scopes: This is where granular visibility can be allotted or removed. Subject matter can range from:

    *Please note: You can have multiple scopes for each permission and restriction

    • Site

    • Department

    • Requester

    • Assignee

    • CC’d On

    • @mentioned in

    • Category

    • Subcategory

    • Buyer (Purchase Order)

    • Supervisor (Users)

    • State (Service Catalog/Solution).

As an administrator, you control and configure user’s visibility, access and restrictions to data as is relevant to their day-to-day operations.

Please see the illustration below:

Notice the list on the right.  This describes the layers of permissions and restrictions that determine each users access.

For example:

  • A user in New York has access to the HR files however the user in the London office does not.

  • The New York and Netanya offices cannot access the IT data however the London office does have this access.

Administrators will find that the creation or alteration of roles is dynamic, and can be adjusted as necessary. In addition to allocating permissions and restrictions, there are further actions that can be taken from the Roles section:

  • Create additional Role Types (e.g. Facilities Service Agent User or Asset Manager)

  • View Users

  • Clone Roles

  • Restore to Default

Below are examples of roles created to suit a variety of organizational needs:
Notice the different Types and Actions utilized in each Role
*Please note: When defining the scope of any role notice the difference between creating multiple rows for permission and restrictions (which we refer to as “or” logic) as opposed to placing multiple permissions and restrictions in the same row (‘and” logic).

  • Read Only

  • Human Resource Service Desk User

  • Facilities Service Desk User

  • Asset Management Agent

  • Vendor Access

Each role type is listed separately in an informational table

To proceed with setup of your SWSD, click here to learn about Domain Mapping.