These Nodes provide tools for flow control, debugging, and explicit error handling during development and runtime. They enable developers to trace execution, control flow termination, and create structured error handling patterns.

• End: Immediately stops flow execution at this point.
• Log Data: Outputs data to a console or debug log for development and troubleshooting.
• Throw Error: Explicitly throws an error within a flow, designed to pair with Try node for structured error handling.

End

This Node immediately stops Flow execution at the point it's invoked. No subsequent Nodes connected after End will execute, regardless of how they're connected.

Common Use Cases:

• Terminating Flow execution early based on conditional logic
• Stopping execution after validation failures
• Preventing unnecessary operations when preconditions aren't met
• Creating explicit exit points in complex Flows with multiple branches

💡💡💡 Tip 💡💡💡

Use End in combination with Conditional Nodes to create guard clauses. For example, check if required data exists, and if not, log an error and use End to prevent further execution that would fail.

📍📍📍 Note 📍📍📍

End stops the current Flow execution entirely. If the Flow was triggered by another Flow, execution does not continue in the parent Flow. For graceful error handling that allows recovery, use Try Node with error paths instead of End.

Log Data

This Node outputs data to the browser console (for PWAs) or debug log (for native apps), making it visible during development and testing. This is essential for debugging Flows, inspecting data transformations, and troubleshooting issues.

To configure Log Data, select the Node on the Canvas and then open the Settings cog in the Right Sidebar.

• Label: Optional descriptive label that appears alongside the logged data, making it easier to identify which log statement produced the output (e.g., "API Response", "User Data", "Validation Result").
• Data: The value to log. This can be:
• • Data from previous Nodes in the Flow
  • Static values for testing
  • FQL expressions to inspect transformed data
  • Complex objects and arrays (will be formatted for readability)
• Log Level: The severity level of the log message:
• • log: Standard informational message (default)
  • info: Informational message with distinct styling
  • warn: Warning message (appears in yellow/orange in most consoles)
  • error: Error message (appears in red in most consoles)
  • debug: Debug-level message (may be filtered in production environments)

Common Use Cases:

• Inspecting API response data to verify structure and values
• Debugging FQL transformations by logging intermediate results
• Tracing Flow execution path by logging at key decision points
• Validating data before passing it to subsequent Nodes
• Troubleshooting conditional logic by logging condition values

💡💡💡 Tip 💡💡💡

Use descriptive labels that indicate both what's being logged and where in the Flow it occurs. For example: "Step 3: User Data After Transform" is more helpful than just "Data" when reviewing logs.

📍📍📍 Note 📍📍📍

Log Data output is only visible during development and testing:

• PWAs: Open browser DevTools (F12) and check the Console tab
• Native Apps: Use platform-specific debugging tools (Xcode Console for iOS, Logcat for Android)
• Flow Tester: Logs appear in the Flow Tester's output panel

💡💡💡 Tip 💡💡💡

Remove or disable Log Data Nodes before deploying to production to avoid performance overhead and potential exposure of sensitive data in console logs. Alternatively, use conditional logic to only log in development environments based on Environment Variables.

💡💡💡 Tip 💡💡💡

When debugging complex Flows, add Log Data Nodes at multiple points to trace execution flow. Use different log levels (info, warn, error) to categorize the importance of each checkpoint.

Throw Error

This Node explicitly throws an error within a Flow, triggering error handling paths defined by Try Nodes or stopping Flow execution if uncaught. This enables structured error handling and custom error conditions.

To configure Throw Error, select the Node on the Canvas and then open the Settings cog in the Right Sidebar.

• Error Message: A descriptive message explaining what went wrong. This message is useful for debugging and can be logged or displayed to users in error handling paths.
• Error Code: Optional error code or identifier that can be used to programmatically handle different error types (e.g., "VALIDATION_FAILED", "AUTH_REQUIRED", "NETWORK_ERROR").
• Error Data: Optional structured data providing context about the error. This can include:
• • Invalid field values that triggered validation errors
  • User input that caused the error
  • API response details
  • Any contextual information needed for error recovery

Common Use Cases:

• Implementing custom validation logic that throws errors for invalid data
• Creating explicit error conditions based on business rules
• Triggering error paths in Try Nodes for graceful error handling
• Failing early when preconditions aren't met
• Simulating errors during testing and development

💡💡💡 Tip 💡💡💡

Always use Throw Error inside a Try Node to enable graceful error handling. The Try Node catches the error and routes execution to the error path, where you can log the error, display user-friendly messages, or attempt recovery actions.

Example Pattern:

1. Try Node invokes validation logic
2. Conditional Node checks if validation passed
3. If failed, Throw Error with validation details
4. Try Node catches error and routes to error handling path
5. Error handler logs error and shows user feedback

📍📍📍 Note 📍📍📍

If Throw Error is executed outside a Try Node (not wrapped in error handling), it will stop the Flow execution immediately. This is similar to End, but provides error context that can be caught by error boundaries higher in the application.

💡💡💡 Tip 💡💡💡

Use the Error Code parameter to distinguish between different error types in your error handling logic. This allows a single Try Node error path to handle multiple error scenarios differently based on the error code.

💡💡💡 Tip 💡💡💡

Include relevant context in Error Data to make debugging easier. For validation errors, include which fields failed and why. For API errors, include the request details. This information is invaluable when troubleshooting issues in production.