> For the complete documentation index, see [llms.txt](https://community-test.logicnets.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://community-test.logicnets.com/release-9/platform-documentation/other-help-articles/setting-conditions-data-validation.md). # Setting Conditions (Data Validation) ## Description The checklist and radio list form parts allow you to set conditions the system verifies before displaying an option or validating a user's selection. It is important to use the right syntax in these *Condition* fields, however, so the system knows what you want it to validate. **Node Type:** *Condition* is a field in Editor of the radio list and checklist form part nodes. It is a field found in most nodes on the *Validate* tab. **Used With:** *Condition* syntax is used with nodes in all frameworks. ## Part Editor The following images show you where to find the *Condition* field in radio lists and checklists. At the question level, validation is found on the Validate tab: ![](https://2802811211-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdFhfexCjZ5JMhwGzzywq%2Fuploads%2Fgit-blob-3fc3d773c2623b1f66b933accfe847d42295a37c%2F065e740e-9c6c-4b79-850d-2d574e3552f1.png?alt=media) For each item, conditions can be specified in the Advanced tab: ![](https://2802811211-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdFhfexCjZ5JMhwGzzywq%2Fuploads%2Fgit-blob-543b343dfbe2e0938b851c4a33a2972e1f6d5af9%2F8a38728a-f591-449d-8314-e6302bf2a3cb.jpg?alt=media) ## Using Syntax The most important tip in using the *Condition* field in a node is to use the correct syntax, and the data object type - are you using text or a number - is the important factor when determining the syntax you should use in the *Condition* field. If you are comparing text you want to compare against text and if you are comparing a number you want to compare against another number. For example: *$(number\_variable)==0* *'$(text\_variable)'=='value'* (note that text objects/values are in single parentheses) #### Operators In the examples above, the == is an operator. This is the symbol that tells the system what you want to do. In the *Condition* field you use operators and additional parentheses to set up simple and complex rules. LogicNets recognizes the following operators in the *Condition* field: \== equals \~= does not equal > or >= greater than, greater than or equal to (numeric only) < or <= less than, less than or equal to (numeric only) Note: "Contains" is not supported until version 7.3 (see below). When setting up conditions on a collection, use the collection\_object\[1] construction. #### Examples of the Correct Syntax Text Objects *('$(cancer\_risk)'=='High Risk' or '$(signs\_infection)'=='yes')* *('$(cancer\_risk)'=='High Risk' and '$(signs\_infection)'=='no')* *('$(cancer\_risk)'=='Low Risk' and '$(signs\_infection)'=='yes' and '$(risk\_infection)'=='moderate')* Numeric Objects *$(test\_score)==0* *$(test\_score)==1* *$(test\_score)>=2* #### Pattern Matching Validation You can also use validation to match simple or complex patterns. For more information on pattern matching, visit Examples: A The strfind below, when pasted into the condition box, will match the input for any alphanumeric in the format AA-AAAAAAA. ``` strfind('$(variable-name)','^[%d,%u][%d, %u]%-[%d, %u][%d, %u][%d, %u][%d, %u][%d, %u][%d, %u][%d, %u]$') ``` B The following example matches for date formats: ``` strfind('$(date_variable)','^[01][0-9].[012][0-9].%d%d%d%d$') ``` #### Using Collection Variables You can use collection variables to have the system display an answer option in a checklist if another variable contains a particular word or phrase; for example, "ABC". By using an XPath query, you can write conditions that verify whether a collection contains specific answers. To do this, enter in the condition field a condition using the following syntax: *$(? \[xpath query]) \~=' '* (Use single quotes with no space between them.) As an example, if you enter in the condition field the query below the system will only display the answer option only IF the data collection called "some\_variable" contains A as one of its answers. ``` $(?/some_array/[contains(this, 'A')]) ~= ' ' or this will also work: ``` ``` $(?/some_array[_.this == 'A']) ~=' ' ``` ``` The above can be expanded for more complex validations and included with other text and numeric validations as follows: ``` To add additional collection values to the check, add to the conditions: ``` $(?/some_array/[contains(this, 'A') or contains(this, 'B')]) ~= ' ' ``` ``` or this will also work: $(?/some_array[_.this=='A' or _.this=='B']) ~=' ' ``` You can also use OR and AND and parentheses to make your validation more complex: ``` $(?/some_array[_.this == 'A']) ~=' ' or '$(text_variable)'=='value' ``` ``` $(?/some_array[_.this == 'A']) ~=' ' and ($(number_variable)==0 or '$(text_variable)'=='value') ``` #### "Does Not Include" To instruct the system to include an answer option only when another variable DOES NOT INCLUDE a value is more complex, because that variable may or may not exist. For simple collections (like checklist objects), you can do this by having the system verify how many "hits" the XPath query generates. The syntax to use for DOES NOT INCLUDE is *'$(? \[xpath query])' \~= '1'*. For example, if you use the condition below for an answer option the system will only display the answer option IF the data collection called "some\_array" does NOT contain A as one of its answers. ``` '$(?/some_array/[contains(this, 'A')])' ~= '1' ``` In the example above, using the ' ' will convert the XPath output to a number of hits or the count of objects that include the value 'A'. The output is represented as text, so any comparisons must also be in single quotes. > * {"A", "A","B"} will return '1' as there is only one object with 'A' (even though 'A' appears multiple times) > * {"AA", "B", "C" } will return '0', as there is no object with 'A' ('AA' will not trigger a match) \[Note that '0' \~= '1' is TRUE, and therefore the answer option WILL display] #### Simple Approach In large or complex collections, where the XPath query has to be defined more tightly to isolate only the target element of the collection, it is always possible to define rules and internal data objects prior to a form part node, rather than in the *Conditions* field, and use those interim data objects in simpler validation rules. It is good practice to develop these rules longhand and verify all eventualities are covered as part of the development process. We recommend using this approach for any validation of arrays that cannot be handled by the simple examples above. ## Example Download this [How To Guide: Validation](/release-9/example-gallery/how-to-guides/asf-how-to-guide-validation-example-project.md) into your Designer for more information on using validation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://community-test.logicnets.com/release-9/platform-documentation/other-help-articles/setting-conditions-data-validation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.