> For the complete documentation index, see [llms.txt](https://doc.wearepatchworks.com/product-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.wearepatchworks.com/product-documentation/process-flows/building-process-flows/dynamic-variables/system-variables.md).
# System variables
**System variables** are values that Patchworks generates automatically at run time. Unlike flow variables, you don't define them - they're always available, and they're resolved for the specific step and payload being processed at the moment the variable is referenced.
Most system variables are unique to the step and payload being processed. The exception is `flow_run_id`, which is the same for every step and payload within a single flow run.
### Available system variables
| Variable | Description |
| --------------------------------- | -------------------------------------------------------------------------------- |
| `system.variables.payload_id` | The unique ID of the payload being processed at the current step |
| `system.variables.flow_run_id` | The ID of the current flow run (shared across all steps and payloads in the run) |
| `system.variables.unix_time` | The current Unix timestamp, in seconds |
| `system.variables.unix_microtime` | The current Unix timestamp, with microsecond precision |
### Referencing system variables
System variables can be referenced in any variable or parameter field using the syntax below:
```
{{ system.variables.payload_id }}
{{ system.variables.flow_run_id }}
{{ system.variables.unix_time }}
{{ system.variables.unix_microtime }}
```
System variables are available in all shapes. For example, they can be:
* Referenced in mappings as custom strings
* Passed as variables in a connector shape
* Accessed directly in the body of an endpoint
{% hint style="info" %}
System variables can be 'mixed and matched' with payload, metadata and flow variables.
{% endhint %}
### Examples
#### Passing a system variable as an endpoint variable
In the example below, a connector shape is configured for a Shopify **Inventory Adjust Quantities** GraphQL endpoint, which expects a `Uuid` variable. Rather than entering a static value, `{{ system.variables.payload_id }}` is entered so that each payload processed by the shape is sent with its own unique ID.
#### Using a system variable to generate an idempotency key
System variables can also be referenced directly in an endpoint body. In the example below, `{{ system.variables.payload_id }}` is used as the `@idempotent` key in a Shopify GraphQL mutation. Because the payload ID is unique per payload, this guarantees that the same inventory adjustment is never applied twice if the request is retried:
```
{"query":"mutation inventoryAdjustQuantitiesWithIdempotency($input: InventoryAdjustQuantitiesInput!) { inventoryAdjustQuantities(input: $input) @idempotent(key: \"{{system.variables.payload_id}}\") { inventoryAdjustmentGroup { createdAt reason referenceDocumentUri changes { name quantityAfterChange delta item { sku variant { id price legacyResourceId product { id totalInventory legacyResourceId }} } } } userErrors { field message } } }",
"variables":{
"input":{
"reason":"correction","name":"available","changes":[[payload]]
}
}}
```
