---
title: "Using guards to add conditions to workflow state transitions"
slug: "using-guards-to-add-conditions-to-workflow-state-transitions"
updated: 2025-08-04T09:39:40Z
published: 2025-08-04T09:39:40Z
canonical: "support.lusid.com/using-guards-to-add-conditions-to-workflow-state-transitions"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Using guards to add conditions to workflow state transitions

You can define a guard within a [task definition](/v1/docs/how-do-i-create-a-task-definition) to control a state transition. A guard is a Boolean expression that operates on field values described [using LUSID’s filtering syntax](/v1/docs/filtering-information-retrieved-from-lusid). A guard must evaluate to ‘true’ in order for the state transition to succeed.

For example, let's imagine you want to model the following simple workflow in a task definition:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/bddd8d49-9892-4e93-93bf-a1fef5427b8d.png)

You might want three possible state transitions, with three possible triggers, two of which have the following conditions:

- The transition from `Pending` to `Approved` should only succeed if a value for the `assignee` field is provided.
- The transition from `Pending` to `Denied` should only succeed if values for the `assignee` and `reasonForDecision` fields are provided.

To enforce these conditions, you can add a guard to each of these state transitions. To do this, call the [CreateTaskDefinition](https://www.lusid.com/docs/api/workflow/endpoints/task-definitions/CreateTaskDefinition) or [UpdateTaskDefinition](https://www.lusid.com/docs/api/workflow/endpoints/task-definitions/UpdateTaskDefinition) API and, within `transitions`, pass in a `guard` value [using LUSID's filtering syntax](/v1/docs/filtering-information-retrieved-from-lusid). This portion of the API request might look like this:

```json
"transitions": [
  {
    "fromState": "Pending",
    "toState": "Approved",
    "trigger": "grant",
    "guard": "fields['assignee'] exists"
  },
  {
    "fromState": "Pending",
    "toState": "Denied",
    "trigger": "reject",
    "guard": "fields['reasonForDecision'] exists and fields['assignee'] exists"
  }
```

If a state transition is attempted but the guard conditions are not met, the request produces an error.

Unique to the Workflow Service, you can also reference a task's `CurrentUser`, `UserCreated` and `UserUpdated` in guard conditions for state transitions. This means you can, for example, prevent a user from approving a data approval task they created themselves. See the examples below for more information.

| **Field** | **Explanation** | **Example** |
| --- | --- | --- |
| `UserCreated` | The user who created the task. | `UserCreated neq CurrentUser` |
| `CurrentUser` | The user who triggered the state transition for which the guard is being evaluated. | `version.userIdCreated neq CurrentUser` |
| `UserUpdated` | The user who last updated the task. If the task has not been updated, this is the same as `UserCreated` (and may in any case be the same user). | `UserUpdated neq CurrentUser` |

Movement from one state to another in the Workflow Service. Each state transition includes a start state, end state and is prompted by a trigger.

A series of one of more task definitions and workers that combine to complete a process.

Modelled as a Mealy state machine, a sequence of states and actions which encapsulate a workflow (or part of a complex workflow). Within a task definition, you can configure parameters for a task, such as states, fields and allowable state transitions. Task definitions also include actions, which can run workers to interrogate your data and generate child tasks. The task definition determines what a particular task does when an instance of that task occurs.

Defined within a state transition, a prompt which induces a state transition to occur in the Workflow Service.