Uniphore Help Center Portal

The toolbar in the upper left of the canvas provides the following controls:

The Debugger Panel runs along the bottom of the Canvas Builder and contains the following tabs:

Click the expand icon to maximize the Debugger Panel.

Every Agentic Workflow must begin with a trigger. A trigger defines how and when the workflow starts, whether that's a manual API call, an incoming webhook, a schedule, a chat message, or a Kafka event. Without a trigger, a workflow execution is not possible.

To add a trigger, click the + icon and select the Trigger category in the Add Node panel. Click a trigger to add it to the canvas.

Once a trigger is on the canvas, double-click it to open its Properties Panel and configure it.

The following trigger types are available:

For a full description of each trigger's configuration options, see Node Types.

// JavaScript example
async function main() {
  const total = execution.quantity * execution.unit_price;
  return { total };
}

# Python example
def main():
    total = execution["quantity"] * execution["unit_price"]
    return {"total": total}

Nodes are the individual steps that make up an Agentic Workflow. Each node performs a specific action: running logic, calling an agent, executing code, interacting with an external service, and so on. Nodes are connected sequentially to define the execution path, and each node can produce an output that subsequent nodes can access.

To add a node to the canvas, click the + icon and select a node from the Add Node panel, or use Copilot to add nodes using natural language. Click a node to add it to the canvas, or drag it to a specific position.

To configure a node, double-click it on the canvas to open its Properties Panel. The Properties Panel varies by node type, but all nodes share the Node Name and Node Description fields. The Node Name is displayed on the canvas and can be used to assign a meaningful label to the node. The Node Description is optional and appears below the node on the canvas.

Each node also has a Node ID, displayed at the bottom of the Properties Panel. The Node ID is used to reference the node's output in expressions and other nodes.

Nodes are organized into the following categories: Triggers, Logic, AI, Agents, and Action Library. For a full description of each node type and its configuration options, see Node Types.

The platform offers a variety of Agent flow task types, enabling quick workflow creation and straightforward configuration. Each node type is designed to handle specific actions within your workflow, making it easy to build complex processes.

Agentic Workflows run in one of two modes:

To run a flow in debug mode, click the Run () icon in the top toolbar, or press ⌘+Enter (Mac) / Ctrl+Enter (Windows).

If your flow has a Manual Trigger, the trigger's Properties Panel opens so you can provide any input variables before the execution starts. Click Run to begin.

While the flow is running, the canvas updates in real time to show execution progress. Completed nodes display a green checkmark and their execution time. The Run button changes to a red Stop button, which you can click to cancel the execution at any time.

The Debugger Panel at the bottom of the canvas opens automatically when a flow runs.

You can pause execution at any node by adding a pause point. This lets you inspect the state of the flow at that point, modify variables, and then continue or step through the flow node by node.

To add a pause point, hover over a node and click the Add Pause Point () icon.

When execution reaches a pause point, the node displays a Paused indicator and execution stops. From here you can:

To remove a pause point, hover over the node and click the Play () icon.

[Also consider Screenshot: Variables tab — editing a variable during a paused execution]

The Logs tab in the Debugger Panel displays a timestamped record of every event that occurred during the execution. Each entry shows the time, severity level (INFO or DEBUG), the node it originated from, and a brief description of what occurred. Click View metadata on any entry to see the full event details.

Use the search bar at the top of the tab to filter entries by keyword. Click the Download () icon to download the logs as JSON.

The tab header displays a running count of log entries. Each execution is assigned a unique Execution ID, which you can use to locate the execution in Run History.

Every time you publish a flow, a new version is created. You can view and manage all versions from the Current Version dropdown in the top toolbar.

To view the list of all versions, click the Current Version dropdown in the top toolbar and click All Versions.

To view a previous version, click the View () icon for that version. The version loads into the canvas in read-only mode.

To promote a previous version to production, click the Promote () icon for that version. This publishes it as the new current version.

To update an app:

To remove an app:

To update a journey:

To remove a journey:

Action Tasks represent workflow activities that invoke MCP tools that you created in the Agent Action Library. Action tasks bring the power of MCP integrations directly into your workflows, enabling your processes to interact with external systems, access real-time data, and perform operations across connected services.

When a workflow reaches an action task, the system automatically invokes the MCP tool and sends any required input parameters. The MCP tool connects to the external systems or database, performs the requested operation, and returns the results. Once the MCP tool returns its response, the workflow engine captures the data and continues execution to the next step in the process.

Common uses for action tasks include:

AI Agent Tasks represent workflow activities that invoke AI agents that you created in the Agent SDK. AI Agent tasks bring AI capabilities directly into your workflows, enabling your processes to leverage custom-built agents for intelligent automation, data processing, and decision-making.

When a workflow reaches an AI agent task, the system automatically invokes the AI agent and sends the input query or data. The AI agent processes the information using its trained capabilities, analyzing content, extracting insights, generating outputs, and making intelligent decisions. Once the AI agent returns its response, the workflow engine captures the results and continues execution to the next step in the process.

Common uses for AI agent tasks include:

Business Rule Tasks enable you to evaluate business rules within your workflows. These rules are defined using Decision Model and Notation (DMN), a standard language for modeling and executing business decisions in a structured, consistent manner.

When a workflow reaches a business rule task, the system evaluates the defined business rules and stores the result in a process variable. The workflow then continues execution based on the evaluation outcome and moves to the next step in the process.

Common uses for business rule tasks include:

A Manual Task is a special kind of task, used to model a task that is performed by a human actor outside of the BPM engine. Manual tasks are typically used to model tasks that are difficult or impossible to automate, such as:

For example, if a process contains a step for "Verify physical documents", that step can be modeled as a manual task because the actual work happens outside the system.

When a process instance reaches a manual task, the engine treats it as a pass-through activity; the process automatically continues to the next step when execution reaches it.

The platform supports manual tasks for modeling and process readability, but they do not behave like other types of tasks, where execution waits for interaction or a system response.

Receive Tasks represent workflow activities that pause workflow execution until a specific message or event is received from an external system. Receive tasks create controlled wait states in which your automated processes must pause until incoming communication arrives.

When a workflow reaches a receive task, the process instance stops at that point and enters a waiting state until the expected message arrives from an external source. Once the message is received and matched to the waiting process instance, the workflow captures the message data and continues execution to the next step in the process.

Common uses for receive tasks include:

Script Tasks represent workflow activities that execute custom scripts or code within your workflows, providing flexibility for specialized logic and data manipulation. Script tasks enable you to embed programming logic directly into your processes for business operations.

When a workflow reaches a script task, the system executes the configured script code in the specified programming language. The script can access and modify workflow variables, perform calculations, transform data formats, or implement custom business logic. Once the script completes execution, the workflow proceeds to the next step in the process.

Common uses for script tasks include:

Send Tasks represent workflow activities that transmit messages or notifications to external systems as part of a business process. Send tasks enable outbound communication from workflows to external recipients, systems, or message brokers.

When a workflow reaches a send task, the system creates a work item for message transmission and executes the send operation through authorized workers. Once the message is successfully transmitted to the external system, the workflow continues execution to the next step in the process.

Common uses for send tasks include:

Service Tasks represent workflow activities that invoke external services or systems as part of a business process. Service tasks are used for automated operations that interact with web services, APIs, external applications, or background workers.

When a workflow reaches a service task, the system automatically invokes the configured external service and sends any required data. Once the external service completes its operation and returns a response, the workflow engine captures the result and continues execution to the next step in the process.

Common uses for service tasks include:

User Tasks represent workflow activities that require human interaction within the workflow system. User tasks are used for activities that need human decision-making, data entry, approval, or review as part of an automated business process.

When a workflow reaches a user task, the platform creates a work item and assigns it to a specific user or group. The process instance pauses at that point, waiting for the assigned user to complete the task through the workflow interface. Once the user submits their response, the workflow engine resumes execution and continues to the next step in the process.

Common uses for user tasks include:

Webhook Tasks represent workflow activities that interact with external systems requiring asynchronous callbacks before the workflow can continue. Webhook tasks enable two-way communication between your workflows and external platforms, making them ideal for processes that depend on external events or actions to proceed.

When a workflow reaches a webhook task, the system initiates the outbound request to the external system and triggers the external event. The process instance then pauses and enters a waiting state until the external system sends a callback response. Once the callback is received and processed, the workflow engine captures the result and continues execution to the next step in the process.

Common uses for webhook tasks include:

An Action Task represents work performed by an MCP tool within a business process. Action tasks are typically used to model activities that interact with external systems, such as retrieving data, updating records, or executing operations, and connect with MCP tools configured in the Agent Action Library environment rather than requiring human interaction.

Action task attributes:

An AI Agent Task represents the work performed by an AI agent within a business process. AI agent tasks are typically used to model activities that require intelligent processing, such as analysis, content generation, or decision-making, and interact with MCP tools tagged with the AI agent rather than requiring human interaction.

AI agent task attributes:

A Business Rule Task is a specific BPMN activity that evaluates and applies business rules or decision logic as part of the process flow.

Within BPMN (Business Process Model and Notation), a Manual Task represents work that requires human intervention, such as decision-making or manual interaction.

In BPMN, a Receive Task is a type of task used to model a specific type of activity in a business process that represents the receipt or reception of a message, notification, or request from an external participant or system. Receive tasks are typically used to depict a point in the process where the process is waiting for an external event, message, or response.

In BPMN, a Script Task is a type of task used to model a specific activity in a business process where a predefined script or code is executed. This script can be written in a scripting or programming language and performs a specific action or set of actions within the process. Script tasks are often used for tasks that involve custom logic, calculations, or operations that cannot be represented using other BPMN elements.

A Send Task models a specific type of activity that represents the process of sending a message, notification, or request to an external participant or system. Send tasks are used to depict a point in the process where information is transmitted to another entity, such as a human user, another process, a service, or an external system.

A Service Task represents work performed by a service or external system as part of a business process. Service tasks are typically used to model automated activities that interact with external services, applications, or systems rather than requiring human interaction.

A User Task in a BPMN journey is an activity that requires human intervention in a business process. When a process instance reaches a user task, a job is created, and the process instance pauses until the job is completed. Users can be automatically assigned to these tasks, or a job worker can manually subscribe to them.

A Webhook Task represents workflow activities that interact with external systems requiring asynchronous callbacks before the workflow can continue. Webhook tasks are typically used to model activities that initiate an outbound request to an external platform and then pause execution until a callback response is received, rather than requiring human interaction.

Webhook task attributes: