---
title: "FEEL Expression Syntax"
slug: "feel-expression-syntax"
updated: 2024-10-08T14:02:22Z
published: 2024-10-08T14:02:22Z
canonical: "docs.processmaker.com/feel-expression-syntax"
---

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

# FEEL Expression Syntax

> [!TIP]
> [**Plan Availability:**](https://www.processmaker.com/products/pricing/) ![Professional](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/Standard.png)![Professional](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/Professional.png)![Enterprise](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/Enterprise.png)

  

Friendly Enough Expression Language (FEEL) is a syntax used to design expressions that calculate values based on dynamic conditions either within [Case data](/v1/docs/request-data-and-json) and/or [Magic Variables](/v1/docs/magic-variables). ProcessMaker Platform uses this Expression Syntax for the following purposes:

****Show or Hide Screen Builder Controls****

Use Expression Syntax Components for **Visibility Rule** settings in Screen Builder controls that describe under which condition(s) that Screen control to display. See an [example](/v1/docs/example-disabling-a-button-until-a-toggle-key-is-selected-without-using-custom-scripts).

If an expression in a control evaluates as True, then that control displays during a Request. If an expression in a control does not evaluate as True, then that control does not display during a Request.

Spaces are allowed before and after expression components, such as [arithmetic](/v1/docs/feel-expression-syntax#arithmetic-operations) and [comparison](/v1/docs/feel-expression-syntax#comparison-operators) operators, to more easily read the expression.

Combine expressions using [logical operators](/v1/docs/feel-expression-syntax#logical-operators). Example: `(not approved) or (cost > 500)`.

> ### Controls with No Visibility Rule Display by Default
> 
> If a Screen control does not have an expression in its **Visibility Rule** setting, then that control displays by default.
> 
> ### Use Magic Variable Values in Expressions
> 
> Use [Magic Variables](/v1/docs/magic-variables) when composing Visibility Rule expressions.
> 
> ### Use Request Variable Values as Dynamic Values in Expressions
> 
> [Request variable](/v1/docs/request-variable) values can be used when composing Visibility Rule expressions. For example, to dynamically compare the `_user.id` Magic Variable value that represents the unique identifier for the user against a Request variable called `BusinessBankerID` that represents the current Request variable value derived from a [Collection](/v1/docs/collections#what-is-a-collection) during a Request, use the "equal to" comparative operator to compare those values: `_user.id == businessBankerId`.
> 
> ### Visibility Rules Override Custom CSS
> 
> If a Screen control affected by a visibility rule is hidden by default from [custom CSS](/v1/docs/custom-css), the visibility rule overrides the custom CSS design. For example, if custom CSS is designed to hide a Screen control by default when that control's visibility rule dictates that it be visible, the visibility rule overrides the custom CSS to display that control. As a best practice, use visibility rules instead of custom CSS to hide a control by default.

****Assign Tasks Dynamically Based on Case Data****

Optionally assign a Task using rules. Rules allow to dynamically assign a Task based on conditions during that Request. When the BPMN element associated with that Task triggers, ProcessMaker Platform evaluates the rule(s) for that element to assign that Task to an assignee.

The following Task-type BPMN elements can use rules to dynamically assign its Task:

- [Form Task elements](/v1/docs/form-task#select-to-whom-to-assign-the-task)
- [Manual Task elements](/v1/docs/manual-task#select-to-whom-to-assign-the-manual-task)

Each rule can only have one expression, but by using logical operators multiple conditions can be specified in that expression. You may use multiple rules to better confine the condition(s) to whom to assign the Task. You may use [Magic Variables](/v1/docs/magic-variables) in your expression syntax.

****Set Conditions for Sequence Flows from Exclusive or Inclusive Gateways****

Specify the condition(s) that must occur in a Request to trigger that Sequence Flow element, thereby triggering its connecting element. By setting different conditions on all outgoing Sequence Flow elements from an Exclusive Gateway or Inclusive Gateway element, you determine the business requirements for each Request of that Process model. ProcessMaker Platform evaluates a Sequence Flow element's condition(s) to trigger by reviewing the Request's data to an expression that describes the condition(s). You may use [Magic Variables](/v1/docs/magic-variables) in your expression syntax.

## Expression Syntax Components

Use the following components to compose FEEL expressions.

- Spaces are allowed before and after expression components, such as arithmetic and comparison operators, to more easily read the expression.
- Combine expressions using logical operators. Example: `(not approved) or (cost > 500)`.
- [Magic Variables](/v1/docs/magic-variables) can be used in when composing expressions.

### **Literals**

| Component | Syntax | Example |
| --- | --- | --- |
| string | `"hello world"` or `'hello world'` | `FullNameInput == "Louis Canera"` |
| number | `100` | `cost > 500` |
| array | `[`value1`, `value2`]` | `myFruit not in ["apples", "oranges"]` |
| Boolean | `true` and `false` | `directorSigned` |

### **Arithmetic Operations**

| Component | Syntax |
| --- | --- |
| addition | `+` |
| subtraction | `-` |
| multiplication | `*` |
| division | `/` |

### Logical Operators

| Component | Syntax |
| --- | --- |
| not | `not` |
| and | `and` |
| or | `or` |

### Comparison Operators

| Component | Syntax |
| --- | --- |
| equal to | `==` |
| not equal to | `!=` |
| less than | `<` |
| greater than | `>` |
| less than or equal to | `<=` |
| greater than or equal to | `>=` |

### String Operator

| Component | Syntax |
| --- | --- |
| concatenate matches | `~` |

### Array Operators

| Component | Syntax |
| --- | --- |
| contains | `in` |
| does not contain | `not in` |

### Range

| Component | Syntax | Example |
| --- | --- | --- |
| range | `..` | `foo in 1..10` |

## Global Data Expression Syntax

ProcessMaker Platform extends [Symfony operators and syntax](https://cdn.document360.io/2d311614-fcb7-4424-8b4c-d4d3091eebeb/Images/Documentation/syntax.html) to access objects and arrays of the main Global Data. To see examples of how to use this syntax, see [Example: Conditional Start Events With Global Data Expression Syntax](/v1/docs/example-conditional-start-events-with-global-data-expression-syntax).

### date

This function extracts the current server date.

### env

This function extracts an [Environment Variable](/v1/docs/environment-variables).

### getActiveTaskAt (node_id, requestId)

This function returns the active Task that corresponds to a **requestId** and **node_id**. If a Task is not found, the function returns null.

### lowercase

This function changes a word to lower-cased.

### process(process_id)

This function returns the Process with the ID supplied **process_id**. If the Process does not exist, the function returns null.

### request(request_id)

This function returns the Request with the ID supplied **request_id.** If the Request does not exist, the function returns null.

### uppercase

This function changes a word to upper-cased.

### user(user_id)

This function returns the user with the ID supplied **user_id**. If the user does not exist, the function returns null.