Conditional Logic

Conditional logic lets one answer change what a respondent sees, can select, must provide, or is allowed to submit. KinoForms evaluates the same dependency rules in preview, on the published form, and during server-side submission validation.

Open the Rule Builder

1. Open a form in the builder.
2. Open Field dependencies.
3. Choose Add rule, or start with a rule under Templates.
4. Give the rule a descriptive name, such as Business accounts need a tax ID.
5. Add one or more conditions under When.
6. Add one or more actions under Then.

Use Edit rules to author rules and Map & test to inspect and simulate them. Changes are saved with the form; publishing is blocked when authoritative validation finds an invalid dependency graph.

How a Rule Works

Every rule has:

• Conditions: the field values the rule reads.
• AND/OR logic: whether every condition or any condition must match.
• Actions: the field state, value, options, or validation the rule changes.
• A name: the plain-language explanation shown in rule lists and traces.

For example:

When accountType equals business, show taxId, make it required, and set its minimum length to 8.

Use AND when all facts must be true. A grant form might request guardian details only when age is below 18 and applicationType is scholarship. Use OR when any matching fact should activate the same actions.

Conditions

The condition selector only offers meaningful inputs for the selected field type. Common groups include:

• Equality and membership: equals, does not equal, is one of, is not one of.
• Text: contains, starts with, ends with, pattern, length, and word count.
• Numbers: greater than, less than, between, integer, decimal places, and divisibility.
• Presence: exists, empty, null, and their inverse forms.
• Dates and times: before, after, within a number of days, and time comparisons.
• Multi-select values: contains an option, is empty, and answer-count checks.
• Format checks: valid email, email domain, URL protocol/domain, and phone country.
• Cross-field checks: compare the current field with another field.

Nested field paths are supported. A field inside a repeating group appears with its full path in the selector so a rule does not accidentally target a same-named field elsewhere.

Actions

Rules can apply more than show/hide branching:

• Visibility: show or hide a field.
• Requirement: make a field required or optional.
• Value: set, clear, or mirror another field's value; forbid two fields from matching.
• Options: allow only specified choices, exclude specified choices, or remove choices already selected in another field.
• Input state: enable, disable, make read-only, or make editable.
• Validation: set a pattern, minimum/maximum length, or minimum/maximum numeric value; prevent two field values from matching.
• Guidance: change placeholder or help text.
• Layout: show or hide wizard steps and tabs when the form uses those layouts.

If several rules change the same property of the same field, treat that as a conflict to resolve, not an ordering trick to depend on. Map & test groups conflicts separately from broken references and cycles.

Conditional Validation Example

Suppose engagementType has fixed scope and ongoing choices. A fixed-scope request needs a budget of at least 1,000; an ongoing request does not.

Create a rule named Fixed scope needs a qualified budget:

1. Condition: engagementType equals fixed-scope.
2. Action: budget Make required.
3. Action: budget Set minimum value to 1000.
4. Action: change the description to explain the minimum.

Then test both paths. The base schema still validates field types and permanent constraints; the matched dependency rule adds the path-specific requirement. Server validation applies the same active constraint, so bypassing the browser does not bypass the rule.

When a field should disappear outside that path, add the complementary rule: hide it and make it optional when engagementType does not equal fixed-scope. This makes the intended inverse behavior explicit and keeps hidden data from blocking submission.

Dynamic Option Filtering Example

Suppose deliveryRegion contains Saudi Arabia, United Arab Emirates, and Global, while servicePlan contains every plan the business offers.

Create one rule for each region:

• When deliveryRegion equals Saudi Arabia, use Filter options (allow only) on servicePlan with the Saudi plan values.
• When it equals United Arab Emirates, allow only the UAE plan values.
• When it equals Global, allow only globally supported plan values.

Use Refine options (exclude) when it is shorter and clearer to identify the few unavailable values. Use Exclude selected value from field for paired choices that must differ, such as first and second preference.

Filtered values use the option's stored value, not only its visible label. In Map & test, confirm both the visible choices and what happens when an answer changes after a choice was already selected.

Test Before Publishing

Open Map & test after creating or changing rules:

1. Enter representative answers in Sample data.
2. Follow green paths in the Dependency map to see which rules matched.
3. Review Affected field state for visibility, requirement, allowed options, values, and validation.
4. Read Rule trace to see each predicate result and applied action.
5. Resolve every error in Logic issues. Review warnings before publishing.
6. Repeat with boundary and inverse cases, not only the expected happy path.

A useful minimum test set is:

• one sample where each rule matches;
• one where each rule does not match;
• equality boundaries such as exactly 18 or exactly 1,000;
• empty and unset values;
• a previously selected option that a later answer filters out;
• every wizard/tab route that can be hidden.

The simulator uses the shared dependency evaluator, but it does not replace the respondent preview. Use the builder's respondent preview once the rule map is clean to verify copy, focus order, layout, and validation messages together.

Import and Export

Choose Export to download the current dependency data as JSON. Choose Import to replace the current rule set with a validated dependency JSON file. Import reports malformed data instead of partially applying it.

Field references are IDs and paths. After importing rules into a different form, resolve any missing source or target references shown in Logic issues before publishing.

Troubleshooting

If a rule does not behave as expected:

• Confirm that the source and target fields still exist.
• Confirm that the comparison value uses the field's stored type and option value.
• Check whether the rule uses AND when it should use OR, or the reverse.
• Look for another active rule changing the same target property.
• Check nested paths after moving or replacing fields.
• Test empty, null, and unset separately when presence matters.
• Resolve circular paths instead of trying to force an evaluation order.
• Reopen Map & test and use the trace to locate the first false predicate.

Published forms receive dependency data with their schema. Invalid rules are rejected by the API at publication time, and active rules are enforced again when a submission reaches the server.

Focused Guides

• Advanced conditional logic
• Conditional validation
• Dynamic option filtering