Purpose

This document helps Zingtree authors debug, validate, and troubleshoot workflows by using built-in logging, execution insights, browser tools, and session tracking.

Logging Overview

Logging is the fastest way to understand what data exists, where it changes, and why a workflow behaves unexpectedly. Zingtree supports logging at multiple layers:

• Content nodes – quick visual checks
• Script nodes – targeted, message-based logging
• Execution Insights – session-level visibility
• Browser Developer Tools – raw request/response inspection

Recommendation: Start with content node logging for fast checks, then move to script logs and Execution Insights for deeper troubleshooting.

Content Node Logging

Content nodes can display variables and workflow data directly in the UI. This is often the simplest way to validate values while stepping through a workflow.

Print a Single Variable

Use variable interpolation to display a single value:

// form data: ${my_variable}
// transforms data: ${transforms.my_variable}
// actions data: ${actions.alias.my_variable}
// views data: ${views.alias.my_variable}

When to use:

• Confirm user input
• Validate transform outputs
• Check conditional values before routing

Print an Object (Stringified)

Objects must be stringified before displaying in a content node:

// transforms data: ${transforms.my_object | stringify}
// actions data: ${actions.alias | stringify}
// views data: ${views.alias | stringify}

Useful for:

• API responses
• Transform outputs
• Validating Dynamic Views selection

📎 Reference: Valid Substitutions & Functions documentation

Print All Available Workflow Data

To display all form data available to the workflow:

##ALL DATA##

When to use:

• You are unsure whether a variable exists
• Debugging complex workflows with many inputs

⚠️ Caution: Remove this before publishing as it may expose sensitive data.

Script Node Logging

Script node logging is similar to console.log() in JavaScript and is used to track variable values during execution.

ZT.log() Basics

• Accepts only one string parameter
• Does not accept raw objects
• Use concatenation or JSON.stringify()

ZT.log("Sample log message: " + myVariable)

ZT.log("Sample log message for object: " +
JSON.stringify(myObjectVariable))

Best Practice: Always include a unique, descriptive prefix in your log message so it’s easy to find in Execution Insights.

Author Tip: Treat ZT.log() like breadcrumbs—log before and after key decisions.

Execution Insights

Execution Insights live in the Apps & Integrations tab of the Zingtree dashboard and provide visibility into workflow execution data.

Location: Apps & Integrations → Execution Insights

Execution Insights Tabs:

• Connected Objects
• Transformations
• Logs

Connected Objects

Connected Object logs show:

• Outbound API requests
• API responses

Important: Logs appear only if Enable Logging is turned on in the Connected Object settings.

Use this to:

• Validate request payloads
• Confirm response schemas
• Debug authentication or mapping issues

Transformations

Transformation logs automatically capture:

• All data passed into a script
• Form data
• API data
• Transform outputs
• View data

Errors: Any script error that triggers an alert modal will also appear here. When opening the accordion of that log, you can see the cause of the script failure in the Error section (in pink).

Recommendation: Check this tab first when a script fails.

Script Logs

Script Logs display values logged manually using ZT.log().

Best uses:

• Tracking conditional paths
• Verifying data mutations
• Confirming execution order

Browser Developer Tools

Browser developer tools provide low-level visibility into network activity.

Inspecting Connected Object Requests

Steps:

1. Open browser developer tools
2. Navigate to the Network tab
3. Execute the workflow
4. Look for requests named with a numeric ID (e.g., 1042)

That number corresponds to the Connected Object ID.

Use this view to:

• Validate request bodies
• Inspect response payloads
• Confirm headers and status codes

Needs clarity: Add a screenshot showing a request selected in the Network tab.

Zingtree Session IDs

A Session ID uniquely identifies a single workflow execution. Session IDs are critical for debugging and reporting.

How Session IDs Are Created

• Generated automatically when a workflow loads without one
• Can be reused to reload a prior session
• Can be manually assigned via URL parameter

Example: Existing Session

https://zingtree.com/preview/123456789?
session_id=my_existing_session_id

Example: Create a New Session

https://zingtree.com/preview/123456789?
session_id=newly_generated_session_id

Best Practice: Use meaningful values (IDs, timestamps, primary keys) for easier troubleshooting.

Finding the Session ID

Option 1: Browser Developer Tools

• Open the Network tab
• Find track-async requests
• Look for X-Session-ID in request headers

Option 2: Usage Reports

• Go to Usage Reports
• Open Session Troubleshooting from the left menu
  
• Locate the relevant session in the Session List report

The Session ID can then be used to filter Execution Insights.

Troubleshooting Checklist

• ✅ Use content nodes to inspect live values
• ✅ Use ##ALL DATA## when unsure what exists
• ✅ Enable logging on Connected Objects
• ✅ Add descriptive ZT.log() messages
• ✅ Check Transformations for script errors
• ✅ Inspect API calls in Execution Insights & browser dev tools
• ✅ Capture and validate Session IDs

Author Recommendations

• Log early, log often — and clean up before publishing
• Prefer descriptive logs over raw values
• Reproduce bugs and capture/share Session IDs
• Validate assumptions at every integration boundary
• Treat Execution Insights as your primary debugging console