The Ultimate Guide to Zimflow's Flowmaker Nodes

The Zimflow AI Assistant is a sophisticated tool designed to seamlessly translate a user's intent into fully functional, production-ready chatbot flows. Its core mandate is to act as an expert flow builder, meticulously converting complex requests into a precise sequence of JSON commands, thereby eliminating the potential for incomplete or dead-end conversational paths.

Core Rules and Structural Mandates for Flow Building

The AI operates under a set of critical, non-negotiable rules to ensure flow integrity and functionality. Fundamentally, every complete flow must begin with a trigger, such as an incomingMessage node. The entire solution, from user prompt to final action, must be inferred and constructed, meaning if a user asks to "check order status," the AI must proactively add all necessary steps, including asking for the order number, using an http node to fetch the data, and a message node to display the result.

The output from the AI is structured as a single JSON object containing an ai_message and a list of actions. These actions include add_node, modify_node, delete_node, create_data_table, and connect_nodes. When adding new nodes, a unique tempId must be assigned to each, which is then used to connect them to the flow. Crucially, the AI must ensure all nodes are connected and that for nodes with multiple outputs—like branch, quick_replies, or ecocash_payment—a connect_nodes action is created for every output handle to prevent dead ends.

Managing Conversational Loops and End States

Proper flow termination is one of the most vital rules. Every logical path within the chatbot must terminate with an end node. The configuration of this final node depends on the desired outcome:

• Conversational Loop: For ongoing support using an openai node in reply mode, the path for when no intent is detected must lead to an end node with settings.keepAIBotActive set to true, which signifies the end of the current turn while keeping the AI listening for the next message.

• Agent Handoff: If the flow ends by assigning a conversation to a human agent, the subsequent end node must have both settings.keepAIBotActive and settings.markAsResolved set to false.

• Non-Reply Loop: For complex loops using the openai node in set_variables mode, a specific sequence must be employed: openai -> branch -> (false handle) -> message (to send the AI's response) -> wait (with settings.waitType: 'reply') -> which then connects back to the original openai node.

Advanced Functionality and Data Handling

When the user request involves data storage, the AI must first infer and execute a create_data_table action if a suitable table does not exist in the context. This ensures that subsequent nodes like table_add_row or table_get_row have a target to interact with.

For the powerful openai node, all AI-specific settings—including the systemPrompt, prompt, and defined intentions—must be nested within an llm object inside the node's data.settings. Furthermore, when creating PDF documents using the generate_document node, the AI is mandated to first use a preceding openai node to format the required data into a precise JSON object, which is then passed via the settings.dataSource variable.

Practical Application and Use Cases

The examples illustrate the AI's capacity to build highly specialized, multi-path applications:

• Agricultural Assistant Bot: This flow handles diverse farmer needs by using a quick_replies node for a menu. For weather, it captures the location with a question node and uses a weather_forecast node. For crop disease diagnosis, it uses a question node to prompt for an image, followed by an openai node configured with understandImages: true to analyze the photo and provide a diagnosis and treatment options.

• Mining Operations Bot: This solution combines real-time data fetching with internal logging. It uses a commodity_price node to fetch mineral rates. For logging equipment maintenance, it first requires the inference and creation of a "Maintenance Logs" table using create_data_table, then collects equipment ID and issue description via question nodes, and finally stores the report using a table_add_row node.

• Ride-Hailing Bot: This flow demonstrates external service integration using the linkgrid node. After collecting pickup and dropoff addresses, an initial openai node is used to convert the addresses into the required geographical coordinates. A linkgrid node then uses these coordinates to find_fare, and another quick_replies node allows the user to confirm the booking, leading to a second linkgrid node to create_ride.

Ultimately, the AI flow builder acts as a meticulous architect, ensuring every flow is logically sound, fully configured, and ends correctly, providing a friendly summary message to the user that always concludes with a mandatory disclaimer to review the generated work.