Value Exists Node - Synthreo Builder

Overview

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 how the downstream connections are configured).

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.

---

What This Node Does

The Value Exists node examines the data flowing through the workflow at that point and checks whether a specific value is present and non-empty. The check can be applied 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 any results before attempting to use those results
• Guarding conditional branches so that only records with complete data proceed to expensive processing steps
• Creating fallback paths when optional data is absent

---

Configuration Parameters

String Operation

• 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.

---

Property Name (Custom Getter only)

• 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, order.total, or Out.gpt_response.
• 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.

---

Branching Logic

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 it 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.

---

Step-by-Step Configuration

Basic Setup

1. Drag the Value Exists node onto the workflow canvas and connect it to the upstream node.
2. Open the configuration panel by clicking the node.
3. In the String Operation dropdown, select your checking method:
   • Choose Input Values to check whether any data came from the previous node.
   • Choose Custom Getter to check a specific named field.
4. If you selected Custom Getter, enter the field name in the Property Name field. Use the smart suggestions to select from available properties.
5. Connect the node’s output paths to the appropriate downstream nodes.

Testing

1. Use the workflow test feature with sample data that includes 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.

---

Common Use Cases and Configuration Examples

Guard Against Missing Email Before Sending

Goal: Only send emails to customers who have a valid email address on record.

Configuration:

• String Operation: Custom Getter
• Property Name: email
• Connect the “Exists” path to the Send Email node.
• Connect the “Does Not Exist” path to a logging node or leave it unconnected to skip the item.

Check Whether a Database Query Returned Results

Goal: Only proceed with AI analysis if the database lookup found matching records.

Configuration:

• Place a Value Exists node after the Input Database node.
• String Operation: Input Values
• Connect the “Exists” path to the LLM analysis node.
• Connect the “Does Not Exist” path to an Output Data node with a “No records found” message.

Validate a Required Order Field Before Processing

Goal: Ensure every order has a shipping address before triggering fulfillment.

Configuration:

• String Operation: Custom Getter
• Property Name: shippingAddress
• Connect the “Exists” path to the fulfillment workflow.
• Connect the “Does Not Exist” path to a notification node that alerts the operations team.

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 node.
• Connect the “Does Not Exist” path to a text-only response node.

Chain Multiple Checks

When multiple fields must all be present before processing, place multiple Value Exists nodes in sequence, each checking one field. The data only reaches the processing step if it passes all checks. This pattern is more readable and maintainable than trying to validate many fields in a single step.

---

Best Practices

• Place Value Exists nodes early in the workflow to catch missing data before it reaches expensive processing steps like LLM calls or external API requests.
• Always handle both output paths. At minimum, the “Does Not Exist” path should connect to a node that logs the skip, returns a fallback message, or flags the item for review.
• When using Custom Getter, verify the property name against the actual data structure by running a test and inspecting the output of the upstream node.
• Property names are case-sensitive. If the upstream node uses customerEmail, writing customeremail will not match.
• For complex validation requiring multiple fields to exist, chain multiple Value Exists nodes rather than relying on a single check.
• Use descriptive node labels (via the node title or an adjacent Annotation node) to document what each Value Exists node is checking, especially in workflows with several conditional branches.

---

Troubleshooting

Node always reports “Does Not Exist” even 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 confirm the property name and its value.
• Check whether the value is genuinely empty (an empty string "" is treated as not existing).

Inconsistent results across different data items

• Confirm that the data format is consistent across all items. If some records use email and others use Email, the check will behave differently for each.
• Consider adding a transformation node upstream to normalize property names before the Value Exists check.

The workflow stops with no output when a value is missing

• The “Does Not Exist” output path is likely not connected. Add a fallback node (Output Data with a default message, or a logging node) on the “Does Not Exist” path to ensure users always receive a response.

---

Integration Tips

• With Output Data nodes: 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.
• With LLM nodes: Gate expensive LLM calls behind a Value Exists check to avoid processing incomplete records and wasting API credits.
• With Update Database nodes: Validate that key fields exist before attempting a database write to prevent failed operations due to missing required columns.