Writing a placeholder instead of fixed text in a rule's value, so two pieces of information are compared with each other — verifying a code the person typed, for example.
You sent the person a verification code and now you need to know whether what they typed is right. You cannot write the code into the rule as fixed text — it is different for every person. The answer is to put a placeholder in the rule's value: the comparison is then made between the two at send time. This article covers which rules support it, how to set it up and where it can mislead you.
real values
💡 The general logic of placeholders and the list of ready-made keys are covered in Variables and placeholders. This article only deals with their use inside condition rules.
Which rules process placeholders
The value box of three rule kinds processes placeholders:
Last reply — The most recent text the person wrote.
Field — The value of a field on the contact card.
Tag — The name of a tag.
The remaining rules do not. Time range, Day and the values picked from a list (Channel, Incoming attachment, Contact's language, Started by, Post) are used exactly as they are; a placeholder written into those boxes is searched for literally and the rule never matches.
How to set it up
Add a Last reply, Field or Tag rule to the condition step.
Pick an operator other than is empty and is filled; a placeholder is only useful where a value is asked for.
Open the placeholder menu below the value box.
Pick a ready-made key from the list, or type a custom field name into the box at the bottom of the menu and add it.
The key is appended to the end of the value box.
You can also type it by hand; the format is double curly braces: {{field.code}}.
Keys you can use
These keys are filled in a rule value:
{{contact.first_name}} — The first word of the person's name. If there is no name, the username is used.
{{contact.name}} — The person's full name. If there is no name, the username is used.
{{contact.username}} — The username.
{{contact.email}} — The email address.
{{contact.phone}} — The phone number.
{{input}} — The most recent text the person wrote.
{{workspace.name}} — The account's name.
{{field.field_name}} — The value of any custom field (for example {{field.code}}, {{field.city}}).
You can give a key a default value too: writing {{field.code|none}} makes the comparison use "none" when the field is empty. That stops an empty field matching unexpectedly.
An unrecognised key is left empty. The pre-publish check reports this with an "Unknown placeholder" warning; the flow can still be published, but that rule will most likely compare against an empty string.
A verification code example
An online course seller verifies attendees like this:
An External request step asks the registration system using the person's email and writes the code on their ticket into the ticket_code field.
A Message step says "Type the 6-digit code from your ticket", with Wait for reply on.
A Condition step: "Last reply · equals · {{field.ticket_code}}".
The True branch sends the joining link. The False branch says "The code did not match" and an Increase/decrease field action adds one to the attempts field; on the third attempt the flow hands over to a person.
The same pattern works for order numbers, appointment codes, coupon validation and membership numbers.
The details of the comparison
Once the placeholder is filled in, the comparison is exactly the same as one against fixed text: case- and accent-insensitive, with leading and trailing punctuation dropped. So if the person types "ABC-123" and the field holds "abc-123", the rule matches.
A small tidy-up also happens while the value is being filled: repeated spaces collapse into one, leading and trailing spaces are dropped, and a space before a punctuation mark is removed. That keeps a stray space inside the field from breaking the comparison.
⚠️ Note: A placeholder cannot be used on both sides. The left side of a rule is always the rule's kind (the last reply, a field or a tag); only the value box on the right takes a placeholder. To compare two custom fields with each other, use the Field rule on the left and the other field's placeholder on the right.
Checking the rule before you rely on it
A rule with a placeholder depends on the field actually being filled. Check two things before publishing.
First, who fills the field. If it is filled by a Collect information, Write to field, External request or AI step, that step must come before the condition. With the order reversed, the rule compares against an empty value and everyone falls onto the same branch.
Second, can the field be empty. If it can, put a step holding "Field · field_name · is filled" in front of the condition, or give the placeholder a default value. Without either, an empty field turns into a silent wrong comparison.
When you try the rule in the simulation on the Test tab, fill the field by hand and walk both branches: enter a matching value and a non-matching one. To test it live, the session log on the Logs tab shows line by line which branch the condition picked.
Limits and known issues
Placeholders are processed only in the Last reply, Field and Tag rules.
With the is empty and is filled operators, the value box is not shown at all and neither is the placeholder menu.
A custom field key is made of lowercase letters, digits and underscores and starts with a letter. {{field.City}} is not recognised.
An unrecognised key stays empty and the pre-publish check raises a warning.
A Field value is at most 200 characters and a Tag value at most 60; the filled text has to fit within that.
In a number comparison (greater than, less than) the filled value must be convertible to a number too.
Once you can compare two pieces of information with each other, every "is this right or not" flow — from identity checks to coupon validation — comes down to a single step.