Start Node

The Start node is the entry point of every Workflow. It is automatically added to the Workflow canvas and does not need to be added from the sidebar.

The Start node prepares the incoming user message before the rest of the Workflow runs. It can provide conversation context through Meta Data and check incoming messages using Guardrails.

How the Start Node Works

Every user message enters the Workflow through the Start node first. This applies to conversations from connected channels as well as messages sent while testing the Workflow.

The Start node performs the following steps:

1. Captures optional conversation context, such as the user’s location or the page URL.
2. Checks the user’s message against any enabled guardrails.
3. Determines whether the Workflow should continue if a guardrail service encounters an error.
4. Passes the message to the connected next node when it is allowed to continue.

The Start node does not generate a response. It prepares the conversation context and checks the incoming message before the next node runs.

The Start node has one outgoing connection to the next node. Incoming connections are not used because Workflow execution always begins at Start.

Configure the Start Node

Select the Start node on the Workflow canvas to open its configuration panel.

The Start node has two main configuration sections:

• Meta Data — Provides additional context to the Workflow.
• Guardrails — Checks incoming user messages against configured rules.

Settings on the Start node are saved automatically. There is no separate Save button on the Start node panel.

Meta Data

The Meta Data section allows you to provide additional context about where the conversation is taking place.

Meta Data is not a privacy or security filter. It makes information such as the user’s location or page URL available to later nodes in the Workflow.

For example, an Agent can use this information to provide different responses depending on the user’s location or the page where the conversation started.

Location

The Location option captures the user’s geolocation and makes it available in the Workflow execution context.

When enabled:

• In Production, the user’s real location is detected automatically.
• In Test, there is no live location lookup. You must provide a temporary test location.

Configure a Test Location

When Location is enabled without a saved test value, the Configure Test Location dialog opens.

Enter a temporary location in the Test Location field and select Save.

The test location is used only while testing the Workflow.

In production, the actual user location is detected automatically.

URL

The URL option captures the web page URL associated with the conversation and makes it available to later nodes.

When enabled:

• In Production, the actual deployment URL is provided.
• In Test, you must enter a temporary URL because a live URL is not detected.

Configure a Test URL

When url is enabled without a saved test value, the Configure Test URL dialog opens.

Enter a valid URL in the Test URL field and select Save.

Example:

https://example.com

The test URL is used only while testing the Workflow.

Meta Data and PII Are Different

The Meta Data and PII sections may contain similar options, such as Location and URL, but they serve different purposes.

Meta Data provides context to the Workflow. PII protects information contained in the user’s message.

Guardrails

Guardrails check the incoming user message before it reaches downstream nodes such as Agent or Knowledge Base.

The Start node provides the following guardrails:

• PII
• Moderation
• Jailbreak
• Custom Prompt Check
• NSFW Filter

All guardrails are disabled by default.

When you enable a guardrail that requires configuration, its settings dialog opens. The guardrail is enabled only after a valid configuration is saved.

The Jailbreak guardrail does not require additional configuration and can be enabled directly.

PII

The PII guardrail detects personally identifiable information in user messages and applies the action you configure.

Available actions are:

The first time PII is enabled, Mask is selected by default.

You must select at least one PII entity or add a valid custom pattern before the guardrail can be enabled.

PII Entities

PII detection supports entities across several categories, including:

• Contact Info — Email Address, Phone Number, Person Name, Location, Date & Time, URL
• Financial — Credit Card, Bank Account, International Bank Account Numbers, Crypto Wallet Address
• Government IDs — Supported government identification numbers
• Medical — Medical License
• Device Identifiers — IP Address, MAC Address
• Addresses — Supported address types
• Additional supported entities for specific countries and regions

Confidence Threshold

The PII confidence threshold determines how confident the detector must be before taking action.

The threshold can be set from 10% to 95%, with a default of 50%.

A higher threshold requires greater confidence before the guardrail takes action.

Custom Patterns

You can also define custom PII patterns using a name and regular expression.

Each pattern includes:

• Pattern Name
• Regex
• Score

A pattern must have a valid name and regular expression before it can be saved.

Moderation

The Moderation guardrail checks incoming content against configured safety categories and can block unsafe requests.

Supported categories include:

• Sexual
• Sexual / Minors
• Hate
• Harassment
• Harassment / Threatening
• Violence

At least one category must be selected for Moderation to remain enabled.

Confidence Threshold

The Moderation confidence threshold determines the minimum confidence required to trigger the guardrail.

The threshold can be set from 50% to 95%, with a default of 70%.

Jailbreak

The Jailbreak guardrail detects prompt-injection and jailbreak attempts before the message reaches downstream nodes.

No additional configuration is required.

Enable the switch to check incoming messages for jailbreak or prompt-injection attempts.

Custom Prompt Check

The Custom Prompt Check allows you to define your own rules for validating incoming user messages.

Unlike Moderation, it does not use a fixed category list. You provide the rules through a custom system prompt.

Configure Custom Prompt Check

The configuration includes:

• System Prompt — Defines the rules used to check user input.
• Confidence Threshold — Determines how confident the check must be before triggering.

The System Prompt is required.

The confidence threshold can be set from 10% to 95%, with a default of 50%.

NSFW Filter

The NSFW Filter checks incoming messages for sexual or explicit content based on the selected categories.

Supported categories include:

• Nudity
• Suggestive
• Explicit

At least one category must be selected for the NSFW Filter to remain enabled.

Confidence Threshold

The confidence threshold can be set from 10% to 95%, with a default of 50%.

Continue on Error

Continue on Error controls what happens when a guardrail service itself fails or cannot complete the check.

It is disabled by default.

When Continue on Error is disabled, the Workflow does not continue if the guardrail service fails.

When Continue on Error is enabled, the Workflow continues to the next node even if the guardrail service cannot complete its check.

Continue on Error applies only to service failures, such as a timeout or server issue. It does not ignore a successful guardrail result.

For example, if PII detection finds personal information and the configured action is Block, that is a successful guardrail result. Continue on Error does not override the Block action.

If the guardrail service fails while Continue on Error is enabled, the protection provided by that guardrail may not have been applied because the check did not complete.

Connect the Start Node

The Start node is automatically available on every Workflow.

Connect its outgoing connection to the first node you want to run after the initial message checks.

For example:

Start → Agent

Or:

Start → Knowledge Base → Agent

Or:

Start → User Feedback → If / Else → Agent

The Workflow then continues through the connected nodes according to the configured path.

What the Start Node Does Not Do

The Start node prepares and checks the incoming message, but it does not perform the work of downstream nodes.

It does not:

• Select a model or generate a response.
• Search a Knowledge Base.
• Ask User Feedback questions.
• End the Workflow.

The End node is optional, but the Start node is required because every Workflow begins there.

Start Node at a Glance