# Parameters and dynamic values
Workflows rely on input **parameters**, values obtained during workflow executions, or from Nexthink data values to enable dynamic, flexible, and context-aware automation.
Workflows use the types of dynamic values described in the following sections.
### 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](https://docs.nexthink.com/platform/user-guide/workflows/creating-workflows/..#add-workflow-parameters).
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**
After defining a workflow parameter, you can dynamically set the parameter's value based on the type of workflow trigger.
For Schedule or Event-type triggers
When configuring a **Schedule** or **Event**-type trigger, choose the values for the parameters :
* A predefined list of values configured in the workflow designer.
* Custom free text values.
* Defined attributes in the `list` statement of the NQL query.
For API triggers
Set the workflow parameter when calling the API from an external system. Refer to the[ API documentation](https://docs.nexthink.com/api/workflows/trigger-a-workflow) for more details.
For Manual triggers
When triggering workflow as a **Manual** action from the Nexthink product (also from Nexthink Amplify) the user is prompted to input the value of the parameter.
Refer to the [#triggeringworkflows-triggeringaworkflowmanually](https://docs.nexthink.com/platform/user-guide/triggering-workflows#triggeringworkflows-triggeringaworkflowmanually "mention") documentation for activating workflows manually.
In the example below, you set the value for the **binary\_name** workflow parameter to the `binary.name` attribute value—from the NQL query—at the real-time event of an execution crash that activates the workflow.
{% hint style="info" %}
Refer to the [triggering-workflows](https://docs.nexthink.com/platform/user-guide/workflows/triggering-workflows "mention") to configure triggers incorporating workflow parameters.
{% endhint %}
#### Referring to workflow parameters
You can refer to global parameters inside Nexthink workflows, for example, to pass the value in the JSON payload of an API thinklet. Use the following syntax:
```json
{{global.parameter_id}}
```
To reference a workflow parameter:
1. Add a parameter to the target workflow.
2. Locate the parameter internal `id` under the **NEAL** tab in the [workflow visual designer](https://docs.nexthink.com/platform/user-guide/workflows/creating-workflows/..#optionally-modify-the-workflow-in-neal).
In the following example, the workflow parameter `p22` has a parameter id of `p_22` in **NEAL** view. See the image below.
```xml
p22
```
{% hint style="warning" %}
Refrain from using the displayed parameter **Name** for parameter references.
In [NEAL](https://docs.nexthink.com/platform/user-guide/workflows/neal#neal-workflowparameters), the XML tag for a workflow parameter is `` due to historical language implementation.
{% endhint %}
***
### 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 [Configuring thinklets](https://docs.nexthink.com/platform/user-guide/workflows/creating-workflows/configuring-thinklets) documentation for details on how to set output 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`
The `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](https://docs.nexthink.com/platform/understanding-key-data-platform-concepts/nql-data-model) using the value contained within the field column as the field name.
{% hint style="warning" %}
Static attributes and [manual custom fields](https://docs.nexthink.com/platform/administration/content-management/custom-fields-management#customfieldsmanagement-choosingmanualcustomfieldtypemanual) are available for use in parameters.
The system does not currently support event data or custom fields computed at runtime.
{% endhint %}
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 when 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 chatbot where these values will be used by the chatbot to move the workflow along later.
```json
{
"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}}
```
