Documentation forSolarWinds Service Desk

SolarWinds Service Desk April 2022 release notes

Release date: April 3, 2022

Last updated: April 12, 2022

These release notes describe the new features and improvements in SolarWinds Service Desk (SWSD). In addition, they provide information about upgrades and detailed workarounds for known issues.

If you are looking for previous release notes for SWSD, see previous version documentation.

New features and improvements

Dynamic Forms and Variables Converted to Custom Fields

SolarWinds delivered two new major features for general availability. These features were requested by many of our customers and are backward compatible. The new features allow greater efficiency and flexibility and enhance user experience.

Overview

This overview provides you with everything you need to know about the new features. It:

  • Explains what changes occurred during an automated migration process performed by SolarWinds.

  • Introduces new concepts.

  • Provides a table of changes that contains a short description of each change and before and after examples.

  • Provides detailed descriptions of the changes, with before and after images.

These changes impacted all customers using the Business, Professional, and Enterprise plans. All setup and configuration of your account did not change during the migration.

Contents of this page

New features

This release includes the two new features below.

SolarWinds released both major features together because they are dependent on one another, and allows us to prepare for a future release of dynamic forms functionality in service catalog.

Benefits of the new features

Reusable custom fields in service catalog items

Previously, when you created a service catalog item, you created individual variables for each service catalog. This made it difficult for you to manage variable updates and report on variables. It also took you longer to create new service catalog items than it will with the new reusable custom fields. All your variables are now custom fields, making them easier to manage and report on.

Dynamic forms for the incidents module

The use of dynamic forms is one of the most powerful changes made to date to SolarWinds Service Desk. Dynamic forms allow you to dynamically change what fields or forms are presented based on user selections. For example, if the priority of an incident or service request changes, dynamic forms can present certain fields in a form when the priority changes. Or if you want to show only certain options in a form after a user enters data, dynamic forms allow you more control over what to show and when to show it. For more information, see Dynamic form rules

New concepts

Custom forms

Historically you would need to create a form for each module and category/subcategory even if the form were the same for multiple modules. The new custom forms allow you to create a standalone form and use it in multiple places, via dynamic form rules, and manage that single form in one place. You can use multiple forms on the same module instead of only being able to have only one form per module. This reduces the time you spend creating and managing your forms.

See Custom Forms for more information.

Dynamic form rules

Historically you were only able to use a form in a single module in SWSD. With dynamic form rules, you can not only use a single form in multiple modules by applying a scope to the form, but also choose when you want that form to be displayed. This new functionality gives you the ability to have a form either appear or disappear based on selections in the scoped module. For example, a form with certain fields can be displayed when a user selects the Applications category, or a different form can be displayed if the user selects the Applications category and sets the priority to High.

See Dynamic Form Rules for more information.

Field logic

Using dynamic forms, you are able to show, hide, and make fields mandatory within a form based on previous selections. This allows you to make sure you can collect the needed information at any given time.

See Field Logic for more information.

Wrapping all three concepts together

You can create custom forms that SWSD displays based on rules defined in dynamic forms used to collect data through custom fields. These fields are also dynamic and can appear or hide themselves based on the logic provided.

Table of changes

Below is a table of the changes occurred during the migration process. The table contains information about the previous state, that is, what was previously available in SolarWinds Service Desk. It also contains information about the new state, that is, is now different because the migration occurred. Comments about each change are also provided. After the table are details about each change, including before and after example images.

Area Previous State New (Existing) State Comments
Custom Forms Custom forms included two fields: module and the category they belonged to.

Custom forms now include only fields.

Display rules in Dynamic Form Rules determine when a custom form should appear.

Migration was automated. No action was required.

You can add/edit rules to show custom forms based on additional fields (for example, priority).

Dynamic Form Rules

This feature was under Labs.

If this feature was not enabled in Labs, all forms were tied to a module on the form level.

Released to General Availability.

Scope now decides where a form can appear, and rules decide when SWSD displays the form.

This new feature changes the way forms are displayed.

You use Scope to choose where a form can appear and rules to identify when that form should appear.

Variables & Custom Fields Use of variables. Variables were unique to each catalog item.

Use of custom fields.

Custom fields are used by all catalog items.

Only unused custom fields can be edited or deleted.

Migration was automated. No action was required.

In addition, a custom field’s scope can be global, making it reusable in other modules.

Field Logic Previously under Labs. Field Logic for custom forms enabled you to control when fields were displayed, hidden, required, optional and more, according to conditions based on other fields in the same form. Released to General Availability.  
Field Logic for Service Catalog N/A

Field Logic is available for Catalog Items.

Dependent dropdown fields were migrated to use Field Logic.

 
Roadmap Items N/A

Contextual conditions (for example, by role)

Validations

Default values

 

Detailed description of changes

Dynamic form rules and field logic

Dynamic forms functionality has two main components: Dynamic Form Rules and Field Logic.

  • Dynamic Form Rules control when custom forms are displayed or hidden based on various conditions, for example Category = Hardware and Priority = Critical.

  • Field Logic controls when fields are displayed, hidden, required, or optional, according to conditions based on other fields located on the same form.

Custom forms

The following changes occurred on custom forms:

  1. Custom forms are standalone and independent of modules.

  2. The module attribute was removed from the form creation page and the custom forms index page.

  3. Going forward, you relate a custom form to a module through Setup > Dynamic Form Rules > New Rule. There you select a scope.

Before the change After the change
Custom forms included fields and the category they belonged to. Custom forms now only include fields. Display rules determine when a custom form appears.

Custom form changes

Existing custom forms with modules were migrated to standalone custom forms with relation to a module using the dynamic form rules, as described below.

Previous State Current State
Existing Custom Form
(Setup > Service Desk > Custom Forms)		 Current State: Custom Form
(Setup > Service Desk > Custom Forms)

Name: Netsuite Form

Module: Incidents > Software > Netsuite

Name: Netsuite Form

Module column removed
 

Dynamic Form Rule
(Setup > Service Desk > Dynamic Form Rules)
 

Name: Netsuite Form: Software > Netsuite

Scope: Incidents

 

Relation

Scope dropdown: Incidents
 

Rule > condition:

Category = Software

Subcategory = Netsuite
 

On True:

Action = Show Netsuite form

Service catalog variables

Service catalog variables were migrated to custom fields to increase efficiency when building and maintaining service catalog items. This makes service catalog variables reusable across all catalog items.

The following changes were made to the service catalog:

  1. Variables were migrated and merged.

  2. A new Scope attribute was created for custom fields.

  3. A new flow was created for adding fields to service catalog items.

  4. Changes were made in available field types.

Migration and merge of variables

Service catalog variables on all instances were migrated to custom fields. The migration and merge process was performed in two steps:

  1. All variables were migrated to custom fields.

  2. Identical custom fields were merged into a single field.

The migration was automated and no action was required on your part.

The migration and merge process differed for each field type as described in the table below.

Data Type Migration and Merge Process*

Text

Checkbox

Date

User

Attachment

  1. Variables were migrated to custom fields of the corresponding field type and were assigned with the Service Catalog scope.

  2. Variables with identical name and type were merged to a single custom field with the same name and type.

Dropdown

Multi-picklist

  1. Variables were migrated to custom fields of the corresponding field type and were assigned the Service Catalog scope.

  2. Variables with identical name, type, and values were merged to a single custom field with the same name, type, and list of values.

  3. If two fields with the same name and type had a different list of values, they were not merged and they now remain as duplicates.

Dependent Dropdown

  1. Variables were migrated to dropdown custom fields.

  2. Dependent dropdown functionality was migrated to field logic.

  3. If two fields with the same name and type had a different list of values, they were not merged and now remain as duplicates.

* See also: Changes in available field types.

Migration example 1 – date variable

Before the change After the change

  • Variable name: Start Date (Date).

  • Variable appears in 30 service catalog items.

In the previous state, variables were unique to each Catalog Item. If you wanted to add a variable to 30 different catalog items, you created one every time you added definitions to each of those catalog items.

  • A single Start Date custom field.

  • The previous variable field relation to catalog items after the migration was to a custom field.

The migration process would have found all 30 appearances of the Start Date field and merged them into a single Start Date field.

Migration example 2 – dropdown variables

Before the change After the change

  • Variable 1:

    • Name: Country

    • Values: Japan, United Kingdom, United States

  • Variable 2:

    • Name: Country

    • Values: Argentina, China, Russia

  • Variable 3:

    • Name: Country

    • Values: Japan, United Kingdom, United States

  1. Because variables 1 and 3 are identical, they were merged into a single custom field. Variable 2 was migrated to a separate custom field (two fields with the same name but different value lists).

  2. The variables’ relationship to catalog items was kept after the migration to custom fields.

New scope attribute for custom fields

Previously, variables were unique to each catalog item which made it hard to manage updates to these variables and collect clean and clear data. As an example, if you wanted to create a variable called Email and use it in ten catalog items, you needed to create it ten different times. Trying to reuse dropdown menus also created a problem because you needed to update multiple dropdowns to collect the same data. There was also the issue of having custom fields that should only have been used in service catalog items and not globally.

To resolve this situation, we not only merged all variables to custom fields but also introduced the ability for you to scope if you want the newly created custom fields to be available globally or just for service catalog items.

The scope attribute was added as described in the table below.

Scope Description Where can I use fields with this scope? Who can create fields with this scope?
Global Automatically assigned to all existing custom fields. Custom forms and catalog items. Admins only
Service Catalog Automatically assigned to all existing variables after they were migrated to custom fields. This scope allows reuse of custom fields across multiple catalog items. Catalog items only. Admins and Agents

 

Selecting scope

When a user who has Manage Setup (Admin) permissions creates a custom field, through setup or a catalog item, the Scope can be selected.

When a user who does not have Manage Setup permissions creates a custom field on a catalog item, the Scope attribute is visible but not editable and the field is assigned to the Service Catalog scope automatically.

New flow for adding fields to catalog items

All custom fields are reusable. As a result, building catalog items becomes easier, with the ability to reuse existing fields.

This requires changing the way users add fields to catalog items. Instead of creating fields, users are directed to the existing fields list:

  1. From a new or existing catalog item, scroll down to the Inputs section (previously Process Fields) and click + Field.

  2. When the Add Field dialog box is displayed, it contains all existing fields. When one of the fields is selected, more information about that field is displayed on the right. If the field is a dropdown or multi-picklist, on the right under the field name you can see three tabs: VALUES, USED IN, and HELP TEXT.

    • If the VALUES tab is selected, the values associated with the dropdown or multi-picklist appear.

    • If the USED IN tab is selected, a list of catalog items that use the field appears.

    • If the HELP TEXT tab is selected, any help text associated with the field appears.

  3. You can check one or more fields you wish to add to the catalog item and then click Add.

  4. You can also create a new field by clicking +New.

  5. After a field is added, it is placed in the catalog item.

Changes in available field types

The field type Dependent Dropdown is no longer available. Instead, users create field logic on any pair of dropdown fields to achieve dependent dropdown functionality.

Here is a list of the new available field types:

  • Text
  • Dropdown
  • Multi-picklist
  • Checkbox
  • Date
  • Date and Time
  • User
  • Attachment

API changes

All request_variables for old incidents are still supported. New incidents show the inputs under custom_field_values.

In addition, the date format for request_variables (previously 2022-04-01) is now the same as for custom_field_values (example: Apr 01, 2022).

For more information, see SolarWinds API Documentation.

What’s next

The change module is not included in this first phase of release. SolarWinds plans to add this new functionality later in 2022.

Along with the change module, SolarWinds plans to add functionality to these features throughout the year. Some of the planned items are:

  • Contextual conditions
  • Input validation
  • Default values

If you have any issues/bugs related to the released features, you can open tickets via either the SolarWinds Portal or by emailing them to technicalsupport@solarwinds.com.

Legal notices

Return to top

© 2022 SolarWinds Worldwide, LLC. All rights reserved.

This document may not be reproduced by any means nor modified, decompiled, disassembled, published or distributed, in whole or in part, or translated to any electronic medium or other means without the prior written consent of SolarWinds. All right, title, and interest in and to the software, services, and documentation are and shall remain the exclusive property of SolarWinds, its affiliates, and/or its respective licensors.

SOLARWINDS DISCLAIMS ALL WARRANTIES, CONDITIONS, OR OTHER TERMS, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE, ON THE DOCUMENTATION, INCLUDING WITHOUT LIMITATION NONINFRINGEMENT, ACCURACY, COMPLETENESS, OR USEFULNESS OF ANY INFORMATION CONTAINED HEREIN. IN NO EVENT SHALL SOLARWINDS, ITS SUPPLIERS, NOR ITS LICENSORS BE LIABLE FOR ANY DAMAGES, WHETHER ARISING IN TORT, CONTRACT OR ANY OTHER LEGAL THEORY, EVEN IF SOLARWINDS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The SolarWinds, SolarWinds & Design, Orion, and THWACK trademarks are the exclusive property of SolarWinds Worldwide, LLC or its affiliates, are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other SolarWinds trademarks, service marks, and logos may be common law marks or are registered or pending registration. All other trademarks mentioned herein are used for identification purposes only and are trademarks of (and may be registered trademarks) of their respective companies.