Building Blocks

Introduction

What are Building Blocks?

Building Blocks are the core components that enable process creation in Zowie Decision Engine. They provide a modular, intuitive framework for designing complex business automation workflows without requiring extensive technical expertise.

These standardized components allow businesses to break down complex customer interactions into manageable, reusable segments that can be easily assembled, modified, and maintained. This modular approach ensures both flexibility and consistency across all automated processes.

Technical Definition

From a technical perspective, Building Blocks are pre-configured process elements with specific functions and configurable parameters. Each block handles a distinct aspect of the customer interaction flow, from collecting information to making decisions to integrating with external systems. Together, they form the foundation of all automated processes within the Decision Engine.

Core Building Blocks

Building Blocks at a Glance

Zowie Decision Engine uses six essential building blocks that work together to create comprehensive automated workflows:

These building blocks can be combined in various ways to create sophisticated customer interaction flows, from simple information gathering to complex multi-step business processes with external system integrations.

Detailed Building Block Descriptions

Zowie Decision Engine includes six essential Building Blocks that serve as the foundation for all process automation:

1. Collect Data

Purpose: Collects and validates specific information from customers during conversations.

Key Features:

• Integration with Data Models for structured information collection
• Intelligent context retention across conversation
• Multiple validation mechanisms (RegEx, LLM-based)
• Ability to extract multiple data points from a single customer message
• Prevention of repetitive questions when information is already available

Technical Configuration:

• Specify required data models to collect
• Define validation rules and error handling
• Configure maximum attempts to prevent conversation loops
• Set context retention parameters

Example Use Case: In an order status workflow, the User Input Gatherer collects the order ID and email address, validates the format of both inputs, and only asks for information that hasn't already been provided earlier in the conversation.

2. Message

Purpose: Delivers responses to customers, with options for both AI-generated and pre-defined content.

Key Features:

• LLM-based response generation based on guidelines
• Option for raw message input for compliance-sensitive scenarios
• Knowledge base integration for enhanced responses
• Dynamic content inclusion using collected data
• Multi-channel compatibility (chat, email, voice)

Technical Configuration:

• Define if the message should be generated by LLM based on a given guideline or Raw - with static text that you provide
• Add relevant variables defined for the process that can be used in the response
• Enrich the responses by adding relevant Policies from your Knowledge - they will be used if relevant to user question and conversation context
• Include follow up questions after providing a response - if this option is enabled the AI Agent will follow up with the user by asking if it can help with anything else. This question will be added directly to the message
• Decide if you want to wait for user input before processing to the next step of the process - if this option is enabled - AI Agent will wait for the user's response before moving forward

Example Use Case: After retrieving order details, the User Message Block generates a response that includes the customer's name, order status, estimated delivery date, and shipping carrier - all presented in a natural, conversational format.

3. Decision

Purpose: Creates branching paths in the process flow based on specific conditions or criteria.

Key Features:

• Predefined modes to build conditions:
  • Creator mode - conditions built on predefined data types and variables
  • Regions - conditions built based on detected user's localisation
  • Human Agent's Availability - conditions built based on whether human agent are available for transfer or not
• Custom Code mode: JavaScript-based condition evaluation
• Multiple outcome paths
• Integration with external systems through API calls
• Access to all previously collected data
• Complex logic support including nested conditions

Technical Configuration:

• Write JavaScript condition expressions
• Define outcome paths for each condition result
• Configure API integrations for external data evaluation
• Set default path for unexpected scenarios

Example Use Case: In a subscription management workflow, the Conditional Block evaluates the cancellation reason provided by the customer. If the reason is "too much product," it routes to an offer for delivery pause; if "too expensive," it routes to a discount offer path.

4. Option

Purpose: The Options Block is a predefined module that combines the functionality of the User Input Gatherer (UIG) and the Condition Block. It allows you to route a conversation based on one of several predefined options selected by the end user or extracted from the conversation history. This block is useful whenever you need to streamline a flow based on user choice — for example, selecting a topic, payment method, or support type.

Key Features:

• Automatic Option Detection: Tries to resolve the correct option from the conversation history before asking the user, similar to the User Input Gatherer.
• Configurable Input Handling: You can decide whether the block should look into the previous conversation context or always prompt the user.
• Guided Questioning: If no option is found in the history, the bot will ask a question defined in the guidance field, using the configured choices.
• Retry Logic: The bot will keep asking until it reaches the configured attemptLimit. After exceeding this limit, the flow follows the failurePath.
• Dynamic Routing: Once a valid option is selected, the conversation moves to the block associated with that option (like in the Condition Block).

Technical Configuration:

• Provide multiple Options - choices - that will be either collected from user or past conversation history
• Define a Guidance that will prompt the LLM to ask the right questions to user in order to detect one of the configured Options
• Configure maximum attempts of collecting users choices to prevent conversation loops
• Select target blocks for each of the defined Options
• Define a fallback path if non of the options match what user provided

Example Use Case:

Goal: Route the user based on their preferred contact method.

In this example, the Options Block is used to determine how a user would like to be contacted.
The block is configured with the following parameters:

• Guidance: “How would you like us to contact you?”
• Choices: Email, Phone, Chat
• Attempt limit: 2
• Failure path: Fallback block

When the flow reaches this block, the system first checks the conversation history to see whether the user has already indicated a preferred contact method.
If such information exists — for example, the user previously said “Please email me” — the block automatically selects the Email option and routes the conversation to the corresponding flow.

If the preferred method cannot be determined from the history, the bot asks the question defined in the guidance field: “How would you like us to contact you?”.
The user can then select one of the predefined choices: Email, Phone, or Chat.

The AI Agent continues to prompt the user until a valid choice is received or the attempt limit is reached.
If the user provides a valid response, the conversation is routed to the block linked to that option.
If the user does not provide a valid answer after two attempts, the flow follows the failure path, directing the conversation to the fallback block.

5. Code (Script)

Purpose: Enables custom logic implementation and integration with external systems.

Key Features:

• Full JavaScript execution environment
• API integration capabilities
• Custom data processing
• Complex business logic implementation
• Data transformation between systems

Technical Configuration:

• Write JavaScript code directly in the interface
• Configure API endpoint access and authentication
• Set error handling and fallback mechanisms
• Define output variables for use in subsequent blocks

Example Use Case: In an order return process, the Code Block connects to the order management system API, validates the return eligibility based on purchase date and product type, calculates the refund amount including any applicable fees, and prepares the return authorization.

6. Call Process

Purpose: Enables reuse of common processes within larger workflows.
Key Features:

• Seamless integration of sub-processes
• Data sharing between parent and child processes
• Reusability of common workflows
• Simplified maintenance of frequently used processes
• Modular design approach

Technical Configuration:

• Select the process to call
• Configure data passing to sub-process
• Define how to handle the return from sub-process
• Set error handling for sub-process execution

Example Use Case: A complex order modification process includes user verification as a step. Rather than rebuilding this verification flow, the Call Another Process Block invokes a pre-built verification process, completes it, and then returns to the main workflow.

7. Finish

Purpose: Concludes the process flow and determines the next action.

Key Features:

• Process completion indication
• Optional handover to human agents
• Transition to reasoning loop or intent recognition
• Conversation continuity options
• Session state management

Technical Configuration:

The finish block supports the following configuration options:

• Return to parent or end process

  If the process is embedded into another process through the “Call another process” option, it will return to the parent process at this point.
  If the process is not embedded, it will finish and trigger tge After Process Ends Moment, if this Moment is enabled.

• Request Transfer

  The process will finish and tigger the Request for Transfer Moment.

• Go to Module

  The process will finish and go to one of the modules selected from the dropdown list. This includes:

  • Handovers – as per the Handover configuration.
  • Surveys – follows the configuration set up in the Survey module.

• Return to Reasoning

  New customer messages will initiate a new reasoning loop, following steps such as intent recognition, searching for knowledge, etc.

  This setting allows choosing if the last user message from the process should be reprocessed by the Reasoning loop. If enabled - Reasoning will initiate intent recognition and knowledge search based on that message.

Example Use Case: After successfully processing a product exchange, the Finish Block concludes the exchange process but keeps the conversation active for any follow-up questions, with access to the context of the completed exchange.

Building Block Integration

Process Flow Architecture

Building Blocks connect sequentially to form coherent process flows:

1. Sequential Execution: Blocks execute in order unless redirected by conditional logic
2. Data Passing: Information collected or generated in one block is available to subsequent blocks
3. Context Retention: User-provided information remains accessible throughout the entire conversation
4. Branching Paths: Conditional blocks create multiple possible execution paths
5. Process Reuse: Sub-processes can be embedded within main processes through Call Another Process blocks

Integration with Data Models

Building Blocks work in tandem with Data Models:

• Collect Data: Uses Data Models to define what information to collect and how to validate it
• Message: Incorporates validated data from Data Models into responses
• Decision: Evaluates conditions based on Data Model values
• Code: Processes and transforms data according to Data Model structures
• Call Process: Passes relevant Data Model instances between processes

Real-World Implementation Examples

Example 1: Subscription Management Process

Start
├── Message: Welcome and identify intent
├── Collect Data: Collect email address
├── Call Process: User Verification (OTP)
├── Code: Retrieve subscription details from API
├── Message: Display subscription details
├── Collect Data: Collect cancellation reason
├── Desicion: Evaluate cancellation reason
│   ├── [Too much product] → Offer delivery pause
│   │   ├── Collect Data: Confirm pause
│   │   ├── [Yes] → Code Block: Process pause
│   │   └── [No] → Continue to cancellation
│   ├── [Too expensive] → Offer discount
│   │   ├── Collect Data: Confirm discount
│   │   ├── [Yes] → Code: Apply discount
│   │   └── [No] → Continue to cancellation
│   └── [Other reasons] → Continue to cancellation
├── Code: Process cancellation in system
├── Message: Confirm action taken
└── Finish Process

Example 2: Order Return Process

Start
├── Message: Welcome and identify intent
├── Collect Data: Collect order ID
├── Code: Validate order exists
├── Collect Data: Collect return reason
├── Collect Data: Collect product condition
├── Code: Calculate refund amount
├── Message: Display return details and refund amount
├── Collect Data: Confirm return
├── Decision: Check confirmation
│   ├── [Confirmed] → Process return
│   │   ├── Code: Create return authorization
│   │   ├── Message: Provide return instructions
│   │   └── Code: Update order status
│   └── [Declined] → Cancel return
│       └── Message: Confirm cancellation
└── Finish Process