Referencing values
The syntax is the same everywhere. What differs is the starting point — the first value an expression begins with. It depends on where you're writing.
| Starting point | Represents | Available in |
|---|---|---|
fieldValue('<field id>') | a field of the current entry | Formula columns, filters |
formValues.get('<key>') | an input on a page | conditional visibility |
step('<step id>') | an earlier step of a Flow | Flows |
today() · now() | today's date · the current moment | everywhere |
true · false | fixed boolean values | everywhere |
loggedInUser() | the signed-in person | everywhere |
owner | the Space's owner | Flows |
The most common mistake is in this table
A starting point that doesn't exist at that spot doesn't produce an error — it produces an empty result. fieldValue('…') in a visibility rule stays silently ineffective, and the block disappears permanently. Check the starting point first, then the function.
Fields of an entry: fieldValue
In a Formula column and in filters, you access the other fields of the same entry:
fieldValue('64f2a1c0b53ff00c6bdf1234').multiplyBy(1.19)The value in the parentheses is the column's id, not its name.
Never type it, always insert it
In the formula editor, the Search tab lists all usable fields by name. A click inserts fieldValue('…') with the correct id and displays it as a colored block showing the field name. That way, the expression shows you the name, while the id is what actually gets stored.
Storing the id has an upside: a formula survives the column being renamed. And a downside: if the column is deleted, the editor reports No field with id … — the field name no longer appears in the expression.
Which fields can be used: Text, Number, Decimal, Currency, Date, Date and time, Created at, Checkmark, User, E-Mail, and Geolocation. Other column types don't show up in the picker.
Formula columns can't reference other formula columns
Fields of type Formula are left out of the picker — otherwise a formula could end up trying to calculate itself. If you need to build on a computed value, repeat the calculation in the new expression.
Inputs on a page: formValues
In a block's conditional visibility, the values come from the input blocks on the same page:
formValues.get('age').greaterThan(17)Access happens via the input block's Key — not its label. You can see all Keys on a page via Manage Keys. → Input blocks
A wrong Key hides the block permanently
If the Key is age and the rule asks for formValues.get('alter'), the condition is always false — the block never appears, without any message. The same thing happens if the Key is changed later.
Settle on meaningful Keys before you build conditions on top of them.
There's a special case with the opposite outcome: if the expression isn't just pointing at nothing, but is syntactically wrong, the block stays visible. So a block that always appears points to a typo; a block that never appears points to a wrong Key.
Results of earlier steps: step
In a Flow, every step produces a result that later steps can access:
step('66f13d06b53ff00c6bdf2769').output.get('email')| Part | Meaning |
|---|---|
step('…') | the step, identified by its id |
.output | the result of that step |
.get('…') | a single field from it |
Here too, nobody types ids by hand: the Flow tab in the expression editor shows the Flow's steps as a tree, and a click inserts the matching expression. The tree is built from the last test run — without a test run it's empty, and the editor says so:
You need to test the Flow first
→ Testing Flows · Passing data between steps
Nested data with multiple gets
Webhook data and JSON responses are often nested. In that case, chain get() calls: step('…').output.get('customer').get('email'). Each get() goes one level deeper.
Date, person, Space
These starting points don't need any connection to an entry or a step:
| Expression | Result |
|---|---|
today() | today's date, without a time |
now() | the current moment, with a time |
loggedInUser() | the signed-in person, with .email, .firstName, .lastName, .id |
owner | the Space's owner, with .email, .firstName, .lastName |
true · false | fixed boolean values |
fieldValue('deadline').before(today())
loggedInUser().email.isEqualTo(fieldValue('assignee'))owner is only offered by the interface in Flows
The three values Space owner email, Space owner first name, and Space owner last name are available in the expression editor as Flow variables. For formulas and visibility rules, the interface doesn't offer them — don't rely on them there.
Who's signed in during a Flow?
loggedInUser() is the person who triggered the action. If a Flow runs via a webhook or a public form, that's not necessarily a member of the Space. For attribution, an explicitly filled-in field is more reliable than the signed-in user.
Which type comes out
In a Formula column, you choose the result's column type under Display result as. The options depend on the type the expression returns:
| Expression returns | Selectable column types |
|---|---|
| Boolean | Checkmark |
| Number | Number, Decimal, Currency |
| Decimal | Decimal, Currency |
| Text | Text |
| Date | Date |
| Date and time | Date and time |
Why the selection sometimes shrinks to one entry
If only one column type is left, the editor sets it for you — the expression doesn't allow anything else. Conversely, a suddenly long list means the expression can't be evaluated yet, and the type isn't determined yet.
Which type an expression is currently returning is shown in the editor above the sample result — Type: String, Type: Number. It also determines which functions are possible next. → Function reference
Next
- Syntax — dots, parentheses, quotation marks
- Building conditions — comparisons, AND/OR, branches
- The expression editor — token view, picker, sample result
- Function reference — every function by type
- Computed fields · Conditional visibility · Input blocks