Revised 07/10/2026
- Toolbox: Mapped vs. Unmapped Questions (Important for Logic Design)
- Expression Basics (How to Write Conditions)
- Conditional Logic Options
- Examples - Practical Grant Application Patterns
- Testing & Troubleshooting Tips
Toolbox: Mapped vs. Unmapped Questions (Important for Logic Design)
In Simple Form Builder, the toolbox is split into two sections:
Unmapped Questions (top section): These questions are not mapped into akoyaGO/Dataverse fields and are used for internal form behavior.
Mapped Questions (bottom section): These are fields from the Request table (and supported lookups such as Applicant/Constituent and Primary Contact/Contact). They are pre-mapped, and no manual mapping is needed or allowed.
More information can be found in GOapply Simple Form Builder - Designer Tab
It is recommended to use unmapped questions as your logic drivers whenever possible (for example, Yes/No toggles), then conditionally show or hide mapped questions or sections based on them.
Expression Basics (How to Write Conditions)
Conditional logic allows you to create rules using an IF → THEN structure.
As mentioned above, this supports actions such as:
- Show / Hide
- Enable / Disable
- Make Required
- Set Answer
- Run Expression
Expressions are written by the logic builder in Simple Form Builder, so you don't need to worry about the correct syntax for typing them. However, the following information can help you understand what the builder creates.
Question Name Is Your Identifier
SurveyJS expressions reference the question name using curly brackets:
For example: {requested_amount} > 50000
SurveyJS replaces {requested_amount} with the GOapply User's response value at runtime.
Expressions Evaluate in Real Time
Expressions update dynamically as applicants answer questions, allowing visibility, read-only status, required settings, and calculated values to change immediately.
Common Operators
SurveyJS supports comparison, logical, and arithmetic operators, including:
=, <, >, <=, >=
and, or
empty, notempty
contains, any of, none of, all of
+, -, *, /
Useful Built-In Functions
SurveyJS supports numerous built-in functions, including:
- iif()today
- ()year
- ()date
- Diff()
- sum()
Example:
iif({org_type} = 'Nonprofit', 'Eligible', 'Review')
Conditional Logic Options
Below are the conditional logic options available to use in Simple Form Builder.
Make the Question Visible If (Visibility / Branching)
Shows a question, panel, or page only when a specified condition evaluates to true.
Example 1 — Fiscal Sponsor Follow-Ups
Scenario: Show sponsor details only if the applicant has a fiscal sponsor.
{has_fiscal_sponsor} = 'Yes'
Example 2 — Large Request Additional Questions
Scenario: Show additional due diligence questions if the request exceeds $50,000.
{requested_amount} > 50000
Example 3 — Multi-Condition Eligibility Gate
Scenario: Show an Eligibility Review panel if the applicant is a nonprofit and serves the West region.
{org_type} = 'Nonprofit' and {service_region} = 'West'
Example 4 — OR Condition (Multiple Paths to the Same Section)
Scenario: Show Student Documentation if the applicant is a student or is applying for a scholarship.
{is_student} = 'Yes' or {app_type} = 'Scholarship'
Disable the Read-Only Mode If (Enable / Disable Editing)
In SurveyJS, this is commonly referred to as "Enable If." A question becomes editable when the condition is true and remains disabled or read-only when the condition is false.
What It Does
Keeps a question visible but prevents editing until a specified condition is met.
Where You'll See It
Property Grid → Conditions
Logic Tab actions such as Enable (Disable) QuestionLogic Tab actions such as Enable (Disable) Page
Examples
Example 1 — Lock Funding Amount Until Eligibility Is Confirmed
Scenario: The applicant must confirm eligibility before entering a requested amount.
{eligibility_confirmed} = 'Yes'
Example 2 — Enable Upload Only When "Yes" Is Selected
Scenario: Enable file uploads only if the applicant indicates they have a 501(c)(3) determination letter.
{has_501c3_letter} = 'Yes'
Example 3 — Enable Follow-Up Explanation When "Other" Is Selected
Scenario: Allow completion of an Other Description field only when the applicant chooses Other.
{org_type} = 'Other'
Tips & Gotchas
Disabled fields may retain previous values. Consider combining Enable If rules with Reset Value If rules when values should be cleared after conditions change.
Make the Question Required If (Conditional Required)
Makes a question required only when a specified condition evaluates to true.
Where You'll See It
Logic Tab → Make Question Required
Required If settings within SurveyJS properties
Examples
Example 1 — Require an Explanation When "Yes" Is Selected
Scenario: Require additional information when the applicant indicates a conflict of interest exists.
{conflict_of_interest} = 'Yes'
Example 2 — Require "Other" Details
Scenario: Require a description when the applicant selects Other as the organization type.
{org_type} = 'Other'
Example 3 — Require Fiscal Sponsor Information
Scenario: Require Fiscal Sponsor Name and EIN if the organization is not a 501(c)(3).
{is_501c3} = 'No'
Tips & Gotchas
Align visibility and required logic whenever possible. Hidden required questions generally should not prevent submission, but matching visibility and validation rules creates the best user experience.
Default Value Expression
Sets an initial value for a question when the survey loads. Once the GOapply User changes the value, SurveyJS will not override it again.
How It Works
Runs one time at load
Uses SurveyJS expression syntax (e.g., {otherQuestion}, today())
Does not react to later changes
When to Use It
Use this when you want to:
Pre‑fill a field once
Use system values (today’s date, logged‑in user data)
Give the respondent a starting value they can overwrite
Examples
Auto‑populate today’s date when the form opens:
"defaultValueExpression": "today()"
Prefill a contact name from another question:
"defaultValueExpression": "{organization_contact}"
This sets a starting value only. Think of it like writing in pencil before someone picks up the pen; once they type something else, SurveyJS leaves it alone.
Clears or resets a question's value when a specified condition becomes true. This helps prevent outdated or invalid answers from remaining when other responses change.
Think of this option like an automatic eraser. If a previous answer no longer applies because another response changed, SurveyJS can erase the outdated value so the form remains accurate and consistent.
How It Works
Continuously evaluates a SurveyJS expression
Triggers whenever the condition evaluates to true
Resets the question back to its default or empty value
Typically used alongside branching logic or conditional questions
When to Use It
Use this when you want to:
Clear answers that are no longer relevant
Prevent users from submitting outdated information
Remove values from hidden questions
Ensure data stays consistent when earlier answers change
Examples
Clear a scholarship details field if the applicant indicates they are not applying for a scholarship:"resetValueIf": "{applying_for_scholarship} = false"
Clear a secondary contact field when the user indicates they do not have a secondary contact:"resetValueIf": "{has_secondary_contact} = false"
Clear a grant amount field if the request type changes:"resetValueIf": "{request_type} != 'Grant'"
Important Notes
The reset occurs whenever the condition becomes true, even if the user previously entered a value.
If the value is cleared, the user may need to re-enter information if the condition later becomes false.
This is commonly used with conditional visibility to ensure hidden questions do not retain outdated responses.
Assigns a value when a condition is true. It will continue to monitor that condition and set the value whenever the condition is met.
This is rule‑based logic. If the rule is true, SurveyJS steps in and sets the value every time. It does not care whether the user typed something different.
How it works
Uses a boolean condition
Sets a static value
Re‑evaluates automatically
Can overwrite what the user entered
When to use it
Use this when:
You want to force a value based on another answer
The value should always stay in sync with a condition
User input should not override logic
Examples
- If applicant type is “Individual,” force a field to “N/A”:
- "setValueIf": "{applicantType} = 'Individual'",
- "setValueExpression": 'N/A'
If “Yes” is selected, set a hidden flag:
"setValueIf": "{hasFiscalSponsor} = true",
"setValueExpression": 'true'
Defines what value should be set, not when. It is usually paired with Set Value If, but it can also run on its own if it references other questions. This option is the “math and logic brain.” It figures out what the value should be and keeps it updated as answers change.
How it works
Uses a full expression
Recalculates whenever referenced values change
Can compute results, concatenate text, or mirror values
When to use it
Use this when:
The value is calculated
The value should always stay in sync with other answers
You want dynamic logic, not just static values
Example (calculation)
Automatically calculate a total:
- "setValueExpression": "{amount1} + {amount2}"
Example (with Set Value If)
Only calculate when a condition is true:
- "setValueIf": "{includeBudget} = true",
- "setValueExpression": "{programCost} + {adminCost}"
Examples - Practical Grant Application Patterns
Pattern 1: Eligibility Gate (Simple & Effective)
Use an eligibility confirmation question to control access to the remainder of the application.
Create an unmapped Yes/No question such as: I confirm I meet the eligibility criteria.
Use Disable Read-Only Mode If (Enable If) logic to unlock the remainder of the application only after the applicant confirms eligibility.
This creates a simple, user-friendly method to prevent applicants from completing irrelevant sections until eligibility has been acknowledged.
Pattern 2: Conditional Documentation
Use visibility and validation together when supporting document uploads.
Example workflow: Ask a Yes/No question that determines whether documentation is required. Use Visible If logic to show the upload field only when appropriate. Use Required If logic to make the upload required whenever it is shown. This approach helps keep forms clean while ensuring applicants provide necessary documentation when applicable.
Pattern 3: Avoiding Contradictory Answers
Use Reset Value If whenever applicants can change earlier answers that affect later questions.
Common examples include:
- Fiscal sponsor qualifications
- Address information
- Organization type selections
- Eligibility indicators
Resetting values prevents hidden fields from retaining outdated responses that may no longer be valid.
Testing & Troubleshooting Tips
Use Preview Mode Early and Often
Simple Form Builder includes a Preview tab that lets you review the experience as an applicant and verify that conditional logic works as expected.
Previewing forms regularly during development helps identify logic issues before the form is published.
*Please note this does not replace testing! Though it allows you to quickly test logic as it is being built, testing is still essential. For more information, please see GOapply Testing Best Practices
If Logic Doesn't Work, Check These First
Question Names
Expressions rely on the question's internal name, not its display label.
Example:
{requested_amount}
If the name is misspelled or does not match the actual question name, the expression will not evaluate correctly.
Value Types
Ensure the values being compared are compatible.
Examples:
Text values should be compared to text values. Numeric values should be compared to numeric values. Date calculations should use date-compatible functions and fields.
Empty Versus Not Empty
Where possible, use built-in SurveyJS operators:
- empty
- and
- notempty
- rather than relying on blank string comparisons.
AND / OR Groupings
Complex expressions often require grouping with parentheses.
Example:
( {org_type} = 'Nonprofit' and {service_region} = 'West' ) or {priority_status} = 'High'
Using parentheses improves readability and ensures expressions evaluate as intended.