Skip to content
synthreo.ai

Value Exists Node - Synthreo Builder

Value Exists node for Builder - check whether a specific variable or field contains a non-empty value and conditionally route workflow execution based on the result.

The Value Exists node checks whether specific data values are present in your workflow and routes execution based on the result. It acts as a conditional checkpoint: if the specified value exists and is non-empty, the workflow continues along the “found” path; if the value is absent or empty, the workflow follows the “not found” path (or stops, depending on downstream connections).

Use this node to validate data before processing it, to guard against missing fields that would cause errors in downstream nodes, and to create conditional branching logic based on data availability.


The Value Exists node examines data flowing through the workflow and checks whether a specific value is present and non-empty. The check applies either to the entire input from a previous node (to verify any data exists) or to a specific named field within the data (to verify a particular property has a value).

Common uses include:

  • Validating that required fields are populated before sending emails or notifications
  • Checking whether a database lookup returned results before attempting to use those results
  • Guarding conditional branches so only records with complete data proceed to expensive processing steps
  • Creating fallback paths when optional data is absent

  • Field name: checkOpId
  • Type: Dropdown
    • Input Values - Checks whether the main data flowing into this node from the previous step contains any values at all
    • Custom Getter - Checks whether a specific named property or field within the data exists and has a non-empty value
  • Default: Input Values
  • When to change: Choose “Custom Getter” when you need to check for the presence of a specific field (e.g., verifying that a customer record has an email address). Use “Input Values” when you simply need to confirm that the previous node produced any output.

  • Field name: valueGetter
  • Type: Smart text field with dynamic suggestions (visible only when “Custom Getter” is selected)
  • Default: Empty
  • Description: The exact name of the field or property to check. Must match the property name as it appears in the workflow data (case-sensitive). For example, email, customerEmail, or order.total.
  • When to change: Enter the specific field name you want to validate whenever “Custom Getter” is selected. Use the smart suggestions to select from available property names and avoid typos.

The Value Exists node has two output paths:

  • Exists (true): Followed when the checked value is present and non-empty. Connect this to the nodes that should run when the data is available.
  • Does Not Exist (false): Followed when the checked value is absent, null, undefined, or an empty string. Connect this to a fallback path, an error handler, or leave unconnected to stop execution for that item.

A well-designed workflow handles both paths. Leaving the “Does Not Exist” path unconnected means items that fail the check silently stop processing - which may be intentional (filtering out incomplete records) or may indicate a design gap.


  1. Drag the Value Exists node from the left panel onto your workflow canvas.
  2. Connect it to the previous node using the arrow connector.
  3. Click on the Value Exists node to open the configuration panel.
  1. In the String Operation dropdown, select your checking method:
    • Choose Input Values for general data validation from the previous node.
    • Choose Custom Getter when you need to check a specific named field.
  2. If you selected Custom Getter, the Property Name field appears. Enter the exact name of the field you want to check. Use the smart suggestions to select from available properties.
  3. Connect both output paths (Exists and Does Not Exist) to the appropriate downstream nodes.
  1. Use the workflow test feature with sample data covering both scenarios - data where the value exists and data where it does not.
  2. Verify that items with the value present follow the correct path and items without it follow the fallback path.
  3. Adjust the Property Name if the node is not matching what you expect.

Business situation: An online retailer wants to ensure customer email addresses exist before sending order confirmations.

Configuration:

  • Set String Operation to “Custom Getter”
  • Enter email in the Property Name field
  • Connect this node after customer data retrieval but before the Send Email node

What happens: The workflow checks if each customer record contains an email address before attempting to send confirmation emails, preventing failed delivery attempts.

Business situation: A healthcare clinic needs to verify that patient intake forms have all required fields completed before scheduling appointments.

Configuration:

  • Set String Operation to “Input Values” to check all incoming form data
  • Connect after form submission but before appointment booking

What happens: The system validates that essential patient information is present before allowing appointment scheduling. Incomplete forms are routed to a follow-up notification.

Business situation: An e-commerce platform wants to verify product availability data exists before displaying items to customers.

Configuration:

  • Set String Operation to “Custom Getter”
  • Enter inventory_count in the Property Name field
  • Place before product display logic

What happens: Only products with valid inventory information proceed to the display step. Items without inventory data are routed to a “check back later” message.

Conditional AI Processing Based on Attachment Presence

Section titled “Conditional AI Processing Based on Attachment Presence”

Goal: Run document analysis only when the user uploaded a file.

Configuration:

  • String Operation: Custom Getter
  • Property Name: base64file
  • Connect the “Exists” path to the document processing or OCR node.
  • Connect the “Does Not Exist” path to a text-only response node.

  • Use Input Values when you want to verify that any data exists from the previous workflow step.
  • Use Custom Getter when you need to check for a specific named field within the data structure.
  • Chain multiple Value Exists nodes in sequence to validate several required fields, one per node.
  • Enter exact field names as they appear in the workflow data - property names are case-sensitive.
  • Use the smart text suggestions to select property names and avoid typos.
  • Test with sample data to confirm the property name resolves correctly.
  • Place Value Exists nodes early in the workflow to catch missing data before reaching expensive processing steps like LLM calls or external API requests.
  • Always plan for both the “Exists” and “Does Not Exist” outcomes. Do not leave the “Does Not Exist” path unconnected without a deliberate reason.
  • Use descriptive labels or adjacent Annotation nodes to document what each Value Exists check is validating, especially in workflows with multiple conditional branches.

Node always reports “Does Not Exist” when the value is present

Section titled “Node always reports “Does Not Exist” when the value is present”
  • Verify the Property Name spelling matches the actual field name exactly, including case.
  • Run a test and inspect the output of the upstream node to see the exact property names and their values.
  • Check whether the value might be an empty string - an empty string is treated the same as a missing value.

Inconsistent results across different data items

Section titled “Inconsistent results across different data items”
  • Confirm that property naming is consistent across all items. Mixed casing (e.g., email vs Email) causes inconsistent behavior.
  • Consider adding a transformation node upstream to normalize property names before the Value Exists check.

The workflow produces no output when a value is missing

Section titled “The workflow produces no output when a value is missing”
  • The “Does Not Exist” output path is likely not connected. Add an Output Data node with Suppress Skipped Execution enabled and a fallback message on the “Does Not Exist” path.

Connect the “Does Not Exist” path to an Output Data node with Suppress Skipped Execution enabled and a fallback message template to ensure users always receive a reply, even when required data is missing.

Gate LLM calls behind a Value Exists check to avoid processing incomplete records and wasting API credits on requests that cannot succeed.

Validate that key fields exist before attempting a database write. A missing key column value would cause the Update operation to fail or match the wrong record.

Use the “Does Not Exist” path to trigger alerts to operations staff when required data is missing from a business process, rather than silently skipping records.