Elzo Forms PRO adds four condition types to a field’s Logic tab: User, Cookie, URL and Date and Time. They decide whether a field is shown using context around the visitor rather than what they have typed into the form.
Use this page once you know how conditions, groups and operators work. The mechanics are the same for every condition type and are covered in Conditional Logic for Fields.
Where these condition types apply
The four types on this page belong to field visibility — the Logic tab of a field, under Show this field if. Together with the Free types (Field value, Authentication, Page) they make seven.
Automations are a separate system with its own condition builder under Run when. It does not use these types: instead you pick a value from the submission and its context — a form field, the authentication status, the user ID or role, the page ID or path, a workflow variable, an earlier action’s result — and compare it with an operator. See Automations Overview.
Every condition here is evaluated twice: in the browser, to show or hide the field, and again on the server when the form is submitted, which is what decides whether the value is stored.
Note: if Elzo Forms PRO is deactivated, conditions of these four types stay in the form, and saving the form does not remove them. The field editor marks each one as requiring PRO, and until PRO is active again it counts as not met, so a rule group that contains one never matches.
User conditions
A User condition looks at the WordPress account of the person filling in the form.
| Operator | True when |
|---|---|
| role is | The user has the role you entered |
| role is not | The user does not have that role |
| role in list | The user has at least one of the roles listed |
| role not in list | The user has none of the roles listed |
| ID is | The user ID matches the number you entered |
| ID is not | The user ID is any other number |
| ID in list | The user ID is one of the numbers listed |
| ID not in list | The user ID is none of the numbers listed |
The value box takes a comma-separated list — editor, shop_manager or 4, 17, 23. The is and is not operators use the first entry only; the list operators use all of them.
Roles are WordPress role slugs, lower case: administrator, editor, author, contributor, subscriber, plus any role a plugin adds. The comparison is exact, so Editor does not match editor. A user can hold more than one role, and role is matches when the named role is among them.
Note: a User condition describes a logged-in visitor. For a logged-out visitor the server matches none of them, the negative operators included, and drops the field’s value. When guests should also see the field, add a group with an Authentication condition set to is guest instead of relying on role is not.
Cookie conditions
A Cookie condition reads a cookie from the visitor’s browser. Choosing this type adds a Cookie name box next to the operator.
| Operator | True when |
|---|---|
| exists | The cookie is present, whatever its value |
| does not exist | The cookie is absent |
| equals | The cookie is present and its value is exactly the text you entered |
| not equals | The cookie is present and its value is anything else |
| contains | The cookie is present and its value contains that text |
| does not contain | The cookie is present and its value does not contain that text |
| matches pattern | The cookie is present and its value matches the regular expression |
Cookie names are case-sensitive and may only contain the characters a cookie name is allowed to have — letters, digits and ! # $ % & ' * + - . ^ _ ` | ~. A name with a space or a semicolon in it never matches.
Note: every operator except does not exist requires the cookie to be there. not equals and does not contain are false when the cookie is missing, not true. To cover “missing or something else”, use two groups: one with does not exist, one with not equals.
Warning: the browser cannot read cookies marked HttpOnly, which includes the WordPress login cookies. A field gated on one of those stays hidden even though the server would match it. Use a User or Authentication condition for login state, and keep Cookie conditions for cookies your own site sets in the browser.
URL conditions
A URL condition compares the full address of the page the form is on, including the scheme, host, path and query string.
| Operator | True when |
|---|---|
| equals | The address is exactly the text you entered |
| not equals | The address is anything else |
| contains | The address contains that text, ignoring letter case |
| does not contain | The address does not contain that text, ignoring letter case |
| starts with | The address begins with that text |
| ends with | The address ends with that text |
contains is the operator to reach for most of the time, because it is the one that sees query parameters. To show a field only to visitors arriving from a campaign link, set contains to utm_source=partner. equals, starts with and ends with compare letter case exactly, and equals has to match the whole address down to the trailing slash — usually more brittle than it looks.
When the form is submitted, the server uses the address the browser reports, and accepts it only when it belongs to this site.
Warning: the URL type also lists a matches pattern operator, but the browser and the server read the pattern differently, so a rule using it can show a field and then discard what the visitor typed into it. Use the other operators until this is corrected.
Because a visitor can edit their own address bar, treat a URL condition as a convenience, never as a gate on anything sensitive.
Date and Time conditions
A Date and Time condition compares the current moment with a moment you pick. Its two operators are is before and is after, and the value box becomes a date and time picker.
Warning: the moment you enter is read as UTC, not as the site’s timezone and not as the visitor’s. For a site three hours ahead of UTC, a field that should open at 09:00 local time needs 06:00 in the picker.
Both operators are exclusive: is after the opening moment becomes true one second later, not at it. Nudge the boundary if the exact second matters.
“Now” comes from the site’s clock, not the visitor’s device, so a visitor cannot bring a field forward by changing their system time.
Building a date range
There is no “between” operator. Put both bounds in one group, where rules are joined with and:
- Date and Time — is after —
2026-11-01T00:00 - Date and Time — is before —
2026-12-01T00:00
The field is then visible through November. For the opposite — visible everywhere except a window — put the two rules in separate groups, so that being before the start or after the end is enough.
Combining PRO conditions
PRO types mix freely with the Free ones inside the same rule group. A group holds an and list, and separate groups are joined with or, so a field shown to editors during a campaign window is one group of three rules:
- User — role is —
editor - Date and Time — is after — the campaign start
- Date and Time — is before — the campaign end
Add one rule at a time and check the form after each. A group that never matches hides the field with no explanation, and a single wrong role slug or timezone offset is enough to cause it.
Security notes
URL values and cookies are supplied by the visitor’s browser and can be changed by anyone. They are fine for tailoring what a form shows, and unfit for deciding who is allowed to do something.
User and Authentication conditions read WordPress’s own session, so they are trustworthy for identity — but they still only control visibility. A field hidden by conditional logic is not saved, yet hiding a field is not access control: anything genuinely sensitive belongs behind WordPress capabilities, not behind a hidden field.
Troubleshooting
A User condition never matches
Check that you are testing while logged in as the intended account, and that the role is written as a lower-case slug — shop_manager, not Shop Manager. Remember that a logged-out visitor matches no User condition at all.
A Cookie condition never matches
Confirm the cookie exists in the same browser, spelled with the same capitalisation. If it is a login or session cookie, the browser cannot read it — switch to a User or Authentication condition.
A URL condition never matches
Compare the value against the address bar in full. equals has to match everything including the trailing slash and the query string; contains with a distinctive fragment is usually what you want.
A Date and Time condition switches at the wrong hour
The value is read as UTC. Subtract your timezone offset from the local time you have in mind, and re-check after a daylight-saving change.
The field appears, then its value is missing from the submission
The condition matched in the browser but not on the server. The known causes are a User condition evaluated for a logged-out visitor and a URL condition using matches pattern. Rebuild the rule with the operators described above.
Next steps
- Conditional Logic for Fields — groups, operators, and what happens to a hidden field.
- Automations Overview — the separate condition builder that decides whether a workflow runs.
- Field Settings — the rest of the settings on a field’s tabs.