Parameters and dynamic values

Effectively using parameters and dynamic values enables IT teams to build automation that behaves dynamically. This section covers defining, configuring, and using them in Nexthink Flow.

Workflows rely on input parameters, values obtained during workflow executions, or from Nexthink data values to enable dynamic, flexible, and context-aware automation. These elements allow workflows to process inputs, adapt to different scenarios, and pass information between workflow steps.

Workflows use the following types of dynamic values:

Workflow Parameters

Workflow parameters define the expected input values for a workflow, ensuring that it can be customized and reused across different scenarios. They are set at the trigger of the workflow and remain constant until the end of the workflow execution.

Use workflow parameters to pass them over inside of the workflows to execute parameterized actions or evaluate as part of conditions.

They can have the values dynamically set at the trigger of the workflow or can remain static values defined at workflow design so they can be referenced throughout the workflow

Define parameters

Parameters are defined as part of workflow design

When adding parameter:

Enter the Name of the workflow parameter.
Enter the mandatory default Value of the workflow parameter.
- Select Allow custom value to enable the parameter to be set at the workflow trigger.

Setting workflow parameters dynamically at the workflow start:

Use the following ways of setting parameters dynamically dependingg on the trigger type:

NQL scheduled or real-time event

When the trigger is based on NQL real time event or schedule, you can pass the parameters that are values returned by the NQL query.

Please note that to set parameters in the schedule, they need to be earlier created in the Designer.

When creating a schedule or real-time event, choose the values for the parameters from the below options:

default parameter value set in the Designer
one of the NQL query output
Custom value defined at the schedule level

Workflow API

Set the parameter of the workflow when calling the API from the external system. Refer to API documentation for more details.

Manual trigger

When triggering workflow as a manual action from Nexthink product (also Amplify) the user will be prompted to input the value of the parameter.

Reference to workflow parameter

You can refer to global parameters inside of Nexthink workflows, for example to pass the value in the JSON payload of API thinklet . Use the following syntax:

{{global.ParameterName}}

Thinklet outputs

Output variables are values that are created and set as part of a thinklet being run. For example, if a remote action collects information and presents it as outputs, these can be used later in the lifecycle of the workflow execution, for example to be used as a parameter of the Remote Action or to pass it as a payload to the ITSM ticket.

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

{{thinkletID.result.outputs.outputid}}

Refer to the detailed thinklet documentation to see details how to set outputs parameters for each thinklet.

Database values

Database values come from the Nexthink platform database. There are two objects that the system can access:

device
user

device and user are objects that are always sent as parameters to the workflow during runtime. When a device is targeted, both of these parameters are populated using the latest information at the time of the workflow being executed.

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.

Only static values are currently available. The system does not support event data and custom fields at this time.

Use the following format when referencing Nexthink fields in the workflow:

{{nx.object.fieldname}}

Example of referencing a device attribute:

{{nx.device.ad_site}}

Example of referencing a user attribute:

{{nx.user.ad.email_address}}

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}}"
        }
    }
}

Using parameters and dynamic values in payload fields

Dynamic values and parameters can be referenced in the Resource and Payload and Message/Text thinklets fields. Include a reference to the data within double braces:

{{}}

Example of Payload to ServiceNow using a Nexthink database attribute:

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

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}}

Last updated 22 days ago

Was this helpful?

{ "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}}" } } }