Designer

Designer provides you with tools to create a workflow using a visual interface. A workflow is a set of instructions and actions that includes the ordering, timing and decisions needed to achieve a specific goal. Create a workflow using a visual programming approach by constructing a logic tree diagram.

Before making any changes to an existing, active workflow design, always disable the workflow first. This prevents the loss of your changes if the changes render the workflow design to be invalid.

Accessing Designer page

To access the Designer interface:

1. Select Workflows from the main menu, and select Manage workflows from the navigation panel.

2. Select a relevant workflow name and then click the Versions tab .

3. Hover over the existing workflow version to reveal the action menu on the right side of the table.

4. Click on the action menu and select Edit the workflow logic.

Understanding Designer interface

The interface contains five main elements.

1. Tabs: Switch between the Designer and NEAL tabs to refine your workflow. The system prompts you to save your changes every time you switch to the other tab. Refer to the NEAL documentation for more information about NEAL scripting capabilities.

2. Canvas: Use the canvas space to connect thinklets and flow controls into a logic tree diagram. Drag-and-drop elements from the toolbar onto the existing code blocks. Each workflow begins with a Start block and ends with the End state. Since you can have multiple branches in your workflow, you may end up with multiple End states.

3. Toolbar: Use the toolbar to add and define the building blocks of your workflow with thinklets and flow controls, and set workflow parameters. Refer to the Adding and removing Thinklets section for more information.

4. Workflow map: Zoom in and out, and frame the entire workflow using the workflow map controls.

5. Save workflow or Close: Click the Save workflow button to commit the changes or Close the Designer space without saving the changes.

Adding and removing Thinklets

Click on the Toolbox tab of the toolbar to add Thinklets and flow controls to the canvas.

• To create your workflow, drag the elements and then drop them onto the canvas. Once you move an element over the canvas, a parking space appears. Touch the parking space with the Thinklet and drop to confirm.

• To remove an element from the canvas, click on the trash icon.

Dropping a Thinklet anywhere outside of the design, cancels the action and leaves the design unaltered.

Adding Thinklets to an existing path

• To add Thinklets, drag the Thinklet from the toolbox to the existing connection path. If the Thinklet is in the correct position, a horizontal line appears, indicating that you can add the Thinklet.

• Drop the Thinklet onto the connection path.

Connecting Thinklets to other workflow branches

It may be necessary to skip certain steps in a workflow and then rejoin the flow later, for example, if a condition is to check whether the software installed on a device is already in the workflow. In this case, you may want to skip the steps of installing the software and continue with the rest of the configuration.

• Hover over the last Thinklet or flow control in a path that has no connection. A pulsing dot appears at the bottom of the Thinklet.

  
• Click and drag from the dot to draw a line. Dots appear on the top of all Thinklets and flow controls, which are valid targets for connection.

• Attach the dotted line to the relevant Thinklet or flow control by attaching the dotted line to the pulsing dot on the Thinklet.

When a Thinklet or flow control has more than one path leading to it, you can remove one of the connection paths. To delete a path:

1. Click on the relevant connection path, and the line appears in bold.

2. Press Backspace/Delete.

The method of connecting branches and deleting unwanted paths can also be used to switch large sections of workflows between condition branches.

Reviewing workflow design issues

If there are problems with the workflow design that prevent it from being valid and activated, these issues will be displayed in the error section of the toolbar when the Save workflow button is clicked.

Review the list and correct any of the issues identified to ensure you have a valid workflow design.

The list of validation issues may contain more problems after the existing ones have been addressed. This is due to some issues blocking further validation of other elements of design.

Validation messages are not available in the NEAL editor. It is necessary to save and switch back to the designer to review the list.

Configuring thinklets

Once you add an element from the toolbar, click on it to reveal its properties.

Remote Action thinklet

The Remote action thinklet sends a remote action to the device targeted by the workflow.

• Name: Enter a unique name for the Remote action thinklet.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the purpose of the thinklet and what it does. This information is useful for other users of the workflow who may not be familiar with it.

• Timeout: Set the timeout in minutes or hours. This dictates how long the workflow waits for a response from the remote action before timing out. When the timeout limit is reached, the workflow enters a failed state and stops processing.

• Select remote action: Identify the remote action that the thinklet will execute. The remote action must have the Workflow trigger configured in order to appear on the list.

• Select device: Select the device on which the remote action will be executed. To apply the device against the executed workflow, ensure the Select device input field is set as a Targeted device.

• Parameters: Configure the required parameters for the remote action.

  • When a remote action has defined parameters, set Allow user to enter a custom value under the Script tab on the Remote action page.

• Outputs: View the outputs of the remote action.

  • When assessing the status of a remote action in a condition, use the following values:

    • 0 for FAILURE

    • 1 for SUCCESS

If you select a device other than the targeted device and use a remote action configured to run as a Service, configure Collector on that device appropriately. Refer to the Running remote actions as service documentation for more information about the configuration.

• Outputs: View the outputs of the remote action.

Campaign thinklet

The Campaign Thinklet sends a campaign to the employee of the device targeted by the workflow.

The workflow uses the responses from single answer questions in the campaign to make decisions defined by conditions, or treats them as inputs to other Thinklets in the workflow.

• Name: Enter a unique name for the campaigns thinklet.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the purpose of the thinklet and what it does. This information is useful for other users of the workflow who may not be familiar with it.

• Timeout: Set the timeout in minutes or hours. This dictates how long the workflow waits for a response from the campaign before timing out. When the timeout limit is reached, the workflow enters a failed state and stops processing.

• Select campaign: Identify the campaign that the thinklet will send. The following criteria are required for a campaign to appear in this list:

  • The campaign trigger is set to Workflow.

  • The campaign contains only single answer questions.

  • The campaign is published.

• Parameters: Configure the parameters for the campaign. This option only appears if the selected campaign is configured to accept parameters.

If you postpone a campaign and want the employee to see it again, set the campaign thinklet's timeout value to over 6 hours.

Service/API thinklet

The Service/API thinklet supports the following connector credential types:

Basic

Bearer

OAuth 2.0 - Client Credentials

OAuth 2.0 - Authorization Code

The Service/API thinklet makes a REST call to an external public API. Use it to retrieve additional information or request actions to be performed.

The Service/API thinklet supports the following call methods:

• GET

• POST

• PATCH

• PUT

• DELETE

The supported payload and response for the Service/API Thinklet are in JSON format.

• Name: Enter a unique name for the Service/API thinklet.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the purpose of the thinklet and what it does. This information is useful for other users of the workflow who may not be familiar with it.

• Credentials: Select the connection credentials for the integration. You must configure them first on the Connector credentials page of the Administration module. Refer to the Connector credentials documentation for more information.

• Request Method: Select the request connection method.

• Resource: Enter the endpoint for the connection.

• Payload: Enter the JSON payload that will be sent to the external system.

Collecting data from API calls

The Service/API thinklet can read data from the response received from a call made to an external system.

It supports up to 5 outputs.

When waiting for a response, the Service\API thinklet waits up to 10 seconds for a response from the external system, after which the call is considered as having failed.

When a response is received the total size of the response received from the external system must not exceed 2 MB of data regardless of whether any outputs are configured.

To configure these outputs:

• Click Add output.

• Name: Enter a name to use as a reference in conditions and thinklet inputs.

• JSON path: Add the JSON path for the data that the system expects to receive. This path should always be prefixed with $. followed by the path to the data delimited by a period. Example of capturing the incident number from ServiceNow:

  $.result.number

The maximum size allowed for JSON Path output is 30 KB or 3840 characters.

Using database and workflow values in payloads

Reference the data of users and devices along with data collected during the execution of the workflow in the Resource and Payload fields.

Format general:

Include a reference to the data within double braces:

{{}}

Example of Payload to ServiceNow using a Nexthink database attribute:

"cmdb_ci": "{{nx.device.name}}“

Format system values:

System values can be used to provide a reference to the current workflow execution. This is useful in the case where the workflow will need to wait for a 3rd party system to perform some actions and then make a call back to the workflow to allow it to proceed.

System values are always prefixed with sys.workflow

A list of these values is represented below.

• sys.workflow.executionId: Is a reference to the id of the currently running workflow execution

• sys.workflow.workflowId: Is a reference to the specific workflow design which is being executed.

An example of the usage of these values is shown below in the context of an integration with a Moveworks chat bot where these values will be used by the chat bot to move the workflow along later.

{
    "message": " Hello, {{nx.user.ad.fullname}}, Your computer is missing some important driver updates, which might be affecting performance",
    "recipients": [
        {{nx.user.ad.email_address}}
    ],
    "context": {
        "slots": {
            "executionid": "{{sys.workflow.executionId}}",
            "workflowid": "{{sys.workflow.workflowId}}"
        }
    }
}

Format thinklet values:

Use the following format when referencing outputs from other thinklets in the workflow:

{{thinkletID.result.outputs.outputid}}

Example of resource for ServiceNow incident update which includes data from a previous Service/API thinklet to log a ticket:

api/now/table/incident/{{log_service_now_ticket.result.outputs.sys_id}}

Format database values:

When fetching data attributes, you can collect data from the device and user objects. The objects’ data will be based on the device or user that the workflow execution is currently running against.

The format for accessing this data is the following:

{{nx.object.fieldname}}

Example of referencing a device attribute:

{{nx.device.ad_site}}

Example of referencing a user attribute:

{{nx.user.ad.email_address}}

For a list of the supported attributes, refer to the device and user sections of the NQL data model using the value contained within the field column as the field name.

Configuring flow control

Condition flow control

The Condition flow control block allows the branching of workflows based on values that have been collected by the workflow or Nexthink data. The system evaluates a condition only once, at the point the workflow execution reaches it.

Conditions accept only one exit point, parallel processing is not supported by Workflows.

In the event that a condition has no valid exit point, the workflow will stop running.

The values that the conditions can evaluate are:

• Thinklet outputs

  • Remote action outputs.

  • Campaign responses.

  • Service/API outputs.

• Workflow parameters

• Database objects

  • device

  • user

• Custom values

Conditions compare values using the following operators:

• Is

• Is not

• Greater than

• Less than

• Greater than or equal to

• Less than or equal to

• Contains

• Does not contain

• Is empty

• Is not empty

The list of available operators is not filtered based on what is allowed to be used for a given data type. Ensure that you can use a given operator on the type of data you are comparing.

• Name: Enter a unique name for the condition flow control.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the purpose of the condition and what it does. This information is useful for other users of the workflow who may not be familiar with it.

• Add condition: Add a condition to the condition flow control.

  • Enter a unique name. This name appears on the canvas and in the NEAL script.

  • Select the source and value for the condition.

  • Select the operator.

  • Select the source and value to be tested against.

  • Add as many conditions as you need.

• Click Done to commit the changes.

The branches appear on the canvas and thinklets and other flow control blocks can now be added underneath them.

When deleting a condition from the workflow design, any design elements underneath the condition will also be lost.

Wait flow control

The Wait flow control lets you pause a workflow and wait for either a period of time or an API call from an external system. This is helpful when the system has to wait for something that it does not have control over.

There are two types of Wait:

• Time delay

• API listener

Time delay

When time delay is selected and configured, the workflow will pause and wait for the specified time and then automatically continue once the time has elapsed.

• Name: Enter a unique name for the Wait flow control.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the purpose of the Wait and what it does. This information is useful for other users of the workflow who may not be familiar with it.

• Type: Select the type of Wait required.

• Value: Set the delay time in minutes or hours. The workflow will pause for this amount of time before it continues to the next step.

API Listener

When API Listener is selected, the workflow will pause and listen for an API call being made to the Trigger WaitFor Event workflow endpoint. Refer to Workflow API documentation for more information

It is possible to configure up to five outputs to capture data from the external system making the call to Nexthink. Use these outputs to either make a branching decision with a condition in the workflow or to provide input information into subsequent thinklets.

• Name: Enter a unique name for the Wait flow control.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the purpose of the Wait and what it does. This information is useful for other users of the workflow who may not be familiar with it.

• Type: Select the type of Wait required.

• Timeout: Set the timeout in minutes or hours. This dictates how long the workflow waits for the desired API call. When the timeout limit is reached, the workflow enters a failed state and stops processing.

• Outputs: Configure up to 5 outputs which are collected from the API call being listened for. The ID of the output will be used for the parameters in the body of the call made to the Trigger WaitFor Event workflow endpoint.

To use the Wait - API listener, make sure the external system knows about the execution and workflow it will interact with.

Send this information using the {{sys.workflow.executionId}} and {{sys.workflow.workflowId}} variables through a Service\API thinklet. The 3rd party system would then record this information to interact with the workflow. See format system value example of how to use these values here

End block flow control

The End block flow control specifies the end of the workflow. Place End blocks at the end of each branch.

The End block is also the place where you can define the workflow outcomes. When the system executes the workflow logic and it reaches the End block, the outcome and outcome details are stored and available to query with NQL.

Use the Outcome and Outcome details fields to retrieve detailed information about workflow executions and display them as KPIs in dashboards.

• Name: Enter a unique name for the End block.

• ID: The system generates the ID automatically based on the name.

• Description (optional): Describe the expected outcome of the workflow at this point in the logic tree. This information is useful for other users of the workflow who may not be familiar with it.

• Outcome: Select from a fixed list of outcomes that best describes what happens at this point:

  • Action taken

  • No action taken

  • Failure

  • Other

• Outcome details (optional): Describe what happens when the workflow reaches the End block. The character limit for this field is 64 characters. Nexthink recommends keeping this description concise in case the information is used on dashboards.

Configuring Connectors

The Connector uses a set of configurations to set up integration events to 3rd party APIs quickly. Nexthink supports the configuration of Connectors with the following third-party applications: Microsoft Entra ID, Microsoft Outlook, ChatGPT, and ServiceNow.

Refer to Configuring Connector thinklet documentation for more information on how to configure connectors thinklets.

Defining Workflow parameters

Workflows use global variables to:

• Accept inputs at the point of execution.

• Define static parameters that the system can:

  • Pass over to thinklets as inputs.

  • Evaluate as part of a condition.

• Under DNS Address,

  • Enter the Name of the workflow parameter.

  • Enter the Value of the workflow parameter.

• Select Allow custom value to allow inputs for the various triggers.

Defininng Workflow details

Use the workflow details section of the toolbar to add a description to the workflow. Describe the intent of the workflow design and any additional information that other users should be aware of when reviewing and editing it.

Reviewing workflow design issues

If there are problems with the workflow design that prevent it from being valid and activated, these issues will be displayed in the error section of the toolbar when the Save workflow button is clicked.

Review the list and correct any of the issues identified to ensure you have a valid workflow design.

The list of validation issues may contain more problems after the existing ones have been addressed. This is due to some issues blocking further validation of other elements of design.

Validation messages are not available in the NEAL editor. It is necessary to save and switch back to the designer to review the list.

RELATED TOPICS

• NEAL

• Creating workflows

• Managing Workflows