This tool allows you to define the conditions and order of operations in the workflow. The purpose of the Gateway is to ensure that, among multiple possible paths, only one is selected and executed based on defined conditions. This allows the process to branch according to different scenarios.
Variables defined in the parameter panel can be called using the Symbol Picker under the “None” option and used in conditions. These variables can be of different data types, such as string, number, boolean, or datetime. The parameter selected via the Symbol Picker is evaluated using a comparison operator specified in the Select Box (e.g., equals, not equals, greater than, less than, contains). If the condition is true, the output path associated with that condition is executed.
Multiple outputs can be defined on an Exclusive Gateway. One of these defined outputs must be designated as the default path using the “Will execute otherwise” option. This path is activated if none of the other conditions listed from top to bottom are met. If, for example, “Yes” is selected for this field, the first path checked in the workflow is evaluated as “No.” Order is important because the system evaluates conditions from top to bottom and does not check paths beyond the first condition that evaluates to true. Conditions can be reordered using drag-and-drop.
The order in which conditions are evaluated directly affects process behavior. The most general condition should be placed at the bottom, and the most specific condition at the top. Otherwise, an unexpected path may be executed if not all conditions are met. It is recommended to add a condition to every exit path. However, at least one path must be set to “Will execute otherwise” so that the path the process will follow when all conditions fail is clearly defined.
This tool is accessed from the Gateways group in the left-hand toolbar.
This is used to branch the workflow in parallel when multiple conditions can be met simultaneously. Unlike the Exclusive Gateway, the Inclusive Gateway ensures that all paths associated with these conditions are triggered simultaneously if more than one condition is true at the same time.
Independent conditions can be defined for each exit path. Conditions are created using variables in the parameter panel via the Symbol Picker. During evaluation, the system evaluates all conditions independently of one another. Therefore, if more than one condition returns “true,” all of these paths are executed simultaneously.
On the Inclusive Gateway, at least one path must be designated as “Will execute otherwise.” This option ensures that the process continues without interruption if none of the other defined conditions are met.
The Inclusive Gateway provides flexible parallel execution in workflow scenarios. For example, in an order process, if both the “Invoice Update” and “Return Request” conditions are met at the same time, the system can initiate both processes concurrently.
The Inclusive Gateway enables business processes to branch dynamically based on conditions and allows multiple operations to be initiated simultaneously.
This tool is accessed from the Gateways group in the left-hand tool panel.
It enables the parallel initiation of multiple tasks that must be executed simultaneously in a workflow or the merging of parallel paths. It is not condition-dependent; therefore, all exit paths are triggered simultaneously.
The Parallel Gateway is typically used for two purposes:
In the Split structure, all output paths connected to the gateway start simultaneously and execute independently of one another. In the Join structure, the Parallel Gateway waits for all parallel paths to complete and proceeds to the next step of the process only when this condition is met.
Using the Parallel Gateway enables time-optimized processes. For example, simultaneously initiating the “Packaging,” “Invoice Preparation,” and “Shipping Label Creation” steps after an order is approved speeds up the process.
Conditions are generally not defined for this tool in the Properties panel, as all paths are triggered automatically. However, the readability of the workflow can be improved by editing the names, descriptions, and connection directions.
This tool is accessed from the Gateways group in the left-hand tool panel.
This tool is the step where automatic tasks to be executed by the system on the Kuika platform are defined. It is typically used to model processes that do not require user interaction. For example, tasks such as making API calls, integrating with external services, updating system parameters, or preparing data in the background are performed in this step.
The System Task step contains two main components: Actions and Step Outputs. The Actions section is where the system actions to be triggered when this step runs are defined. Here, one or more previously defined actions can be executed sequentially. These actions can, for example, be a REST API call or send data to a previously defined Custom Action to receive a response.
Actions related to authorization can also be added from this section: Using the Add User To Role and Remove User From Role actions, you can automatically add or remove a user from a specific role when the step runs. For example, after an approval process is completed, the “Approved Users” role can be automatically assigned to the relevant user.
The Step Outputs section is where the data obtained as a result of the action is mapped to parameters that will be used in the workflow. In this section, the “+SELECT WF PARAMS TO MAP” option is used to determine which variables the values returned by the action will be assigned to. This ensures that values received from external systems or calculated in the background can be used later in the workflow for a condition, notification, or another task.
This task type does not display any forms or notifications to the user. It manages operations that take place entirely in the background. When placed appropriately, it automates the workflow and eliminates the need for manual intervention. Each System Task step can be configured not only to perform a single operation but also but also to execute a series of consecutive automated steps together.
This tool is accessed from the Activities group in the left-hand toolbar.
This tool is used to define tasks in the workflow that require manual data entry and approval from the user. It is used in situations where the user must perform a specific action, enter data, fill out a form, or make a decision. The process does not proceed to the next step until the user completes the assigned task. Therefore, User Task steps function as critical decision points or data collection points in the process.
User Task offers flexible configuration options for designing interactive processes with users in the system. This step can be linked to a form to collect data from the user and can be customized with various fields such as user-specific assignments, notifications, descriptions, due dates, and buttons.
This tool is accessed from the Activities group in the left-hand tool panel.
Properties Panel:
Example Buttons:
In Kuika’s Process Automation module, the Forms tab is used to manage business processes and to configure and visualize user-interactive steps. This tab ensures that the screens (forms) created for each business process are grouped under the relevant process and managed in an organized manner.
Each workflow has its own screen group. Thus:
The Forms tab consists of two sub-tabs: one titled Workflow Screens and the other Interactions. Next to each sub-tab is a counter indicating how many items are defined in that tab (e.g., “Workflow Screens 1,” “Interactions 0”). Changes are saved using the APPLY SCREENS button in the upper-right corner; they can be canceled using CANCEL.
In both sub-tabs, a list of all User Task steps in your process is displayed on the left under the USER TASKS heading. Steps can be filtered using the search box. When a step is selected from the list, the relevant content for that step (form fields or interactions) opens on the right.
In this sub-tab, the form fields (fields) are defined.
When a step (e.g., “Sample Step”) is selected from the USER TASKS list on the left, the following are displayed on the right:
Section Structure
A form is divided into one or more Sections. Each section is displayed as a separate block on the form. The following information is defined for each field added within a section:
To add a new field, click the + ADD FIELD button (select the field type from a drop-down menu).
To add a new section, use the + Add Section link at the bottom of the page. A section with no fields added yet is displayed as an empty drag-and-drop area with the message “This section will appear as a separate block on the form.” and the text “Drag a field here to create it.”
In this sub-tab, user interactions (buttons/User Interactions) associated with the selected step are managed.
When a step is selected from the USER TASKS list on the left, two sections open on the right:
To add a new interaction, use the + ADD NEW USER INTERACTION link in the upper right corner.
What Is a User Interaction?
The User Interaction element is used to define steps in a workflow that require human interaction, such as direct user feedback, form filling, decision-making, or the entry of specific data. This step separates the business process from system actions and requires user input.
Use Cases:
Technical Specifications:
Interaction Flow:
Tracking and Reporting:
Tips and Best Practices:
Advanced Usage: Form Integration
A form linked to a step in the “Workflow Screens” sub-tab supports the following features:
Multi-Instance settings are configured via the Multi-Instance Configuration panel under the Advanced tab when a step is selected. This structure applies to both Parallel Multi-Instance (PMI) and Sequential Multi-Instance (SMI).
Sequential Instance Count Strategy (SMI)
When the Sequential structure is selected, the instance generation method is specified in the Instance Generation field.
Manual (Number / Symbol): The number of instances is specified manually. In the subfield Instance Count (Fixed/Variable):
The specified number of instances is created and executed sequentially.
Based on Step Assignment: The number of instances is determined based on the step’s Assignment type. If the Assignment type is Role or Dynamic, instance generation follows this configuration.
Instance generation logic:
If Dynamic Assignment is used:
In a sequential structure, the processing order of instances can be specified:
Instances are created and executed sequentially according to the selected order.
Available in Sequential Multi-Instance steps. When the defined condition is met, any remaining instances that have not yet been executed are not created, and the process is terminated.
Conditions are defined using the AND GROUP structure.
The method for aggregating the results returned by child instances is specified in this section.
Child Output Key: Select the child output field to be included in the aggregation.
Strategy: Supported strategies:
Depending on the selected strategy, the child results are aggregated into a single output and transferred to the parent flow.
When the Parallel structure is selected:
In the Process Automation module, information about the user who initiates a process can be accessed via the Symbol Picker. This information is referred to as the Process Initiator and can be used as a dynamic value in various steps of the workflow (Task, User Task, Notification, Gateway conditions, etc.).
In the Symbol Picker, the following fields under Process Initiator can be selected individually:
This way, depending on the scenario, instead of displaying only the first and last name, functional data—such as the user’s email address—can be directly selected via the Symbol Picker and passed to actions.
Example Usage: In a leave request process, when the outcome of the request (approved/denied) needs to be communicated to the Process Initiator, an email can be sent directly to the user who initiated the process by selecting Process Initiator → Mail from the Symbol Picker in the “Recipients” field of the “Send Mail” action.
