Roles and Permissions

On this page

Introduction

Each individual using SolarWinds Service Desk (SWSD) is assigned a role to identify their specific access within the application. Depending on the role assigned to them, users can navigate to specific areas within SWSD, in addition to being assigned permissions and/or restrictions. The permissions/restrictions provide an added level of control for administrators to manage users within your organization.

When setting roles in SWSD you can create your own custom roles and associate them with permissions, restrictions, and users.

When creating a new role, a name and description should be provided. You can also define whether the role is for self-service portal access only.

The world view with regards to permissions is that each role starts with no permissions at all. You then start adding permissions to the role. Per permission you can also add certain restrictions.

The view of the permissions and restrictions is top down so you should consider the order when adding permissions that may contradict previous restrictions or permissions.

Navigation

ITSM customers	ESM customers
Setup > Account > Roles & Permissions	Organization (or Service Provider) > Account > Roles & Permissions

Before you begin

Before beginning any work in the Roles & Permissions module, it is important to understand the different types of roles available and the permissions granted to those roles.

It is also important for Enterprise Service Management (ESM) customers to understand what they can do at the Organization level vs. the Service Provider level.

ESM customers

ESM Organization level administrators manage roles at the Organization level. Although Service Provider administrators cannot provision users, they do have the ability to create and manage their own roles and permissions.

For roles provisioning, an administrator needs to create a dedicated app for each service provider in the SAML platform(s) your company uses.

Role types

The Roles screen displays and outlines the permissions and restrictions for each role, the action the role can perform, the areas of SWSD where the actions can be performed, and the scope for each.

There are four main role types in SWSD:

• Administrator (license required)
• Service Agent User (license required)
• Service Task User (license NOT required)
• Requester (license NOT required)

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

Role types for ESM customers

Enterprise Service Management (ESM) customers have the following available for customization at the organization level:

• Administrator (license required)
• Users and Groups (Service Agent User license required)
• Requester (license NOT required)

The Users and Groups role has permissions one level below administrator. It is available only to ESM customers at the organization level. The role is allocated for an administrator of service providers, and it allows them to manage groups to support the business needs.

License-required roles

Users with license-required roles typically access SWSD through the platform website.

Administrator

The Administrator role exhibits the highest level of access to the application through the organization's service desk website. All users assigned as administrators have complete access to all areas of the setup. They can delete items (for example, assets, knowledge articles, service requests, and incidents) unless restrictions have been placed on the specific user.

Administrators can grant agent roles specific permissions to:

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

• Setup areas (defined by menu blocks): Account, Users & Groups, Integrations, Global Settings, Service Desk settings, CMDB, Discovery & Assets, and Labs.

By granting permissions to service agent user roles, an administrator can delegate ongoing setup activities such as workflows, automations, and notification setup for specific agents.

The Administrator role is a licensed role and counts toward the number of licenses your organization purchased.

By clicking the View Users button in the upper right, you can see a list of the users who are assigned the Administrator role.

The Administrator role is the only role that can enable APIs within workflow processes on your SWSD (backend and frontend). Each administrator who needs to enable APIs must use token-based authentication. See Token authentication for API integration for more information.

Service Agent User

The Service Agent User role is one level below an administrator. Service Agent Users do most of their work through the organization's service desk website. This role is allocated for technicians, giving them access to the system in order to work on incidents or manage assets. Service Agent Users cannot access the Setup menu, cannot delete anything, and cannot manage benchmarks. If you want to limit some service agent users from working on incidents or managing assets, you would add a restriction based on scope.

Using the buttons in the upper right, you can:

• 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, the action CANNOT be undone.
• Add Permissions.
  • Define the Action allowed such as: Manage, Read, or Create.
  • Define the Subject within objects and setup. This allows the Service Task User to have access to some or all the setup actions in the setup menu.
  • Define the scope ().
    

By hovering over a row, you can use the three buttons to the right of that row to:

• Add Restriction. Define a new restriction.
• Edit. Click the pencil icon to edit the existing restriction.
• Delete. Click the trash can icon to delete the selected restriction.

The Service Agent User role is a licensed role and counts toward the number of licenses you purchased.

License-not-required roles

Users with license-not-required roles typically access SWSD through the portal.

Service Task User

Users in this role have access to the service portal, allowing them to submit incident and requests and view knowledge base articles. The Service Task User role is considered an elevated requester, and therefore can 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 or from their email.

Using the buttons in the upper right, you can:

• 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, the action CANNOT be undone.
• Add Permissions.
  • Define the Action allowed such as: Manage, Read, or Create.
  • Define the Subject within objects and setup. This allows the Service Task User to have access to some or all the setup actions in the setup menu.

By hovering over a row, you can use the three buttons to the right of that row to:

• Add Restriction. Define a new restriction.
• Edit. Click the pencil icon to edit the existing restriction.
• Delete. Click the trash can icon to delete the selected restriction.

The Service Task User role is a non-licensed role.

Requester

The Requester role is for service portal access only. Users in this role can use the portal to submit incidents, and service requests and view knowledge base articles. Requesters can also carry on ongoing correspondence using My Requests from the portal.

For end users to use @mention, you need to add Read: Users permission to the Requester role. You can also create a restriction that limits Requesters to seeing only the users in their department or site, or to their supervisor.

Using the buttons in the upper right, you can:

• 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, the action CANNOT be undone.
• Add Permissions.
  • Define the Action allowed such as: Manage, Read, or Create.
  • Define the Subject within objects and setup. This allows the Service Task User to have access to some or all the setup actions in the setup menu.

By hovering over a row, you can use the three buttons to the right of that row to:

• Add Restriction. Define a new restriction.
• Edit. Click the pencil icon to edit the existing restriction.
• Delete. Click the trash can icon to delete the selected restriction.

The Requester role is a non-licensed role.

Individuals with a Requester role cannot be assigned tasks or approvals.  If someone with the Requester role needs to attend to tasks or approvals, their role must first be changed to Service Task User.

Permissions and restrictions

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

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.  For example, you could grant a permission at the Service Task User level, but restrict it at the department level.

Several articles listed below will guide you in the setup of roles and permissions. In addition, there are some examples for building roles for departments other than IT, such as Facilities, Human Resources, and Marketing.

Understand terminology related to roles and permissions

It is important to understand the following terms so you can 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 and 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. Allows user to create content.

  • Read. Allows user to consume data.

    If an individual or group has permission to manage only incidents and computers, the individual (or group that person is a member of) might also need permission to read user accounts.

  • Update. Allows user to make changes to existing content within the scope of the user's permissions.

    If a managed permission has a scope defined, then users who need to be able to edit records related to that scope would need Update permissions. See Permissions.

  • Delete. Allows user to remove data from the system.

  • Manage. Allows user to perform all actions within the scope of the user's permissions.

    When Read or Manage restrictions are assigned to a role, selecting certain restrictions will remove visibility of specific sections. For example, removal of the Asset modules from the view of specific users.

• Subject. Encompasses the module of the platform that a permission or restriction is allocated to. Subject includes:

  • Modules of the service desk (ex: incidents, problems, changes)
  • Inventory (ex: computers, other assets)
  • Procurement

• Scopes. Where granular visibility can be allotted or restricted.

  You can have multiple scopes for each permission and restriction.
  Subject matter for scopes includes, but is not limited to:
  • Site
  • Department
  • Requester
  • Assignee
  • CC’d On
  • @mentioned in
  • Category
  • Subcategory
  • Buyer (Purchase Order)
  • Supervisor (Users)
  • State (Service Catalog/Solution).

User visibility and access

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

In the image below you can see the Permission/Restriction List on the right.  It describes the layers of permissions and restrictions that determine each user's 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.

The creation or alteration of roles in SWSD is dynamic and can be adjusted as necessary. In addition to allocating permissions and restrictions, further actions can be taken from the Roles section:

• Create additional role types (for example, a facilities service agent user or an asset manager)
• View users
• Clone roles
• Restore to default

New roles

Below are some examples of roles that can be created to suit a variety of organizational needs. Notice the different types and actions used in each role.

Read Only access

Human Resource Service Desk User access

Facilities Service Desk User access

Asset Management Agent access

Vendor access

Each role type is listed separately in an informational table

Options

From the Roles screen, using the buttons to the right of each role you can see the number of users assigned to the role and view a list of those users. You can also clone a role, restore the settings to default, and add permissions.

By hovering over a specific permission or restriction type for a role, you can add restrictions, edit restrictions, or delete restrictions.

Create a new role

1. From the Roles & Permissions index page, click New Role in the upper right.

2. In the Create Role dialog, add the name of the new role and a short description, then select the user license type from the dropdown menu.

   

3. Click Create Role to save.

Edit an existing role

From the Roles & Permissions index page, you can add a permission to a role by selecting the role, and then clicking Add Permission to the far right of the user role.

Under the user role you can also hover to the far right of a permission or restriction and:

• Click Add Restriction to create a new restriction.

• Click the pencil icon to the right of the permission or restriction to edit.

• Click the trash can to the right of the permission or restriction to delete it.

Add permissions

See Add permissions.

Related topics

• Setup resources
• Users