Signals by UnifyApps coordinate work across two or more automations — a child automation emits a signal when its portion is complete, and the parent's Wait Signal action resumes only after all expected signals have arrived.

Overview

Signal actions are capabilities within UnifyApps designed to manage intricate asynchronous operations, particularly when handling parallel processing and parent-child automation relationships.

There are two signal actions: the Wait for Signals action (used in parent automations) and the Emit Signal action (used in child automations). Together they let a parent automation launch many child automations in parallel and then wait until all of them report back before proceeding.

Wait for Signals action

A control node in a parent automation that pauses execution until it receives all specified signals from child automations. Think of it as a collection point that waits to hear back from all child processes before moving forward.

• Signal IDs

A list specifying which signals the Wait Signal action should wait for. For example, if processing multiple orders:

1. Create an empty list called signalList before the loop.

2. Inside the loop, add identifiers (such as the loop index) to signalList.

3. Map this signalList to the Wait Signal action's Signal IDs field.

The node knows exactly which signals to wait for and tracks which child automations have responded before proceeding.

• Signal Payload Schema

Defines the structure of the response you expect from child automations — for example, a status field and an error field. You can define the schema by adding fields manually, using a code snippet, or mapping from a previous step.

Emit Signal action

Used in child automations to send processing results back to the parent automation's Wait Signal action. When a child automation completes its processing, the Emit Signal action sends both the signal (matched against the parent's Signal IDs list) and the processing results (matching the parent's defined payload schema).

• Waiting Instance ID and Runtime Type

These are the parent automation's identifiers and must be passed to the child automation through the callable trigger:

• Waiting Instance ID — the parent automation's execution ID

• Waiting Instance Runtime Type — the parent workflow's runtime type

Map both values from the callable input to maintain the connection between parent and child.

• Automation Selection and Node

First select the parent automation, then choose the specific Wait Signal node that should receive this response. This ensures signals are delivered to the correct waiting point in the parent automation.

• With Signal ID

Enable this option to match signals with their corresponding Signal IDs in the parent's wait node, ensuring each child's response is properly tracked.

• Signal Parameters

Map your actual data from the child automation to the fields defined in the parent's Signal Payload Schema. For example, if the parent expects status and result, provide those values here.

Example: Parallel Order Processing

Suppose you receive 1,000 orders that need to be processed. To handle this efficiently:

In the Parent Automation

1. Fetch the list of 1,000 orders.

2. Create an empty list orderSignals.

3. Loop over the orders:

   • For each order, add the loop index to orderSignals.

   • Start the child automation for that order using a Callable trigger.

4. Add a Wait Signal node, map orderSignals to its Signal IDs, and define the expected response schema (status, processing time).

5. After all signals are received, continue to the next step.

In the Child Automation

1. Each child processes one order.

2. After processing, the Emit Signal action:

   • Maps Waiting Instance ID and Runtime Type from the callable input.

   • Sends the signal back to the parent with the success/failure status and processing details.

Instead of processing 1,000 orders sequentially (1,000 minutes), all orders are processed in parallel — potentially completing the entire batch in a few minutes.

Notes

Signals work best when you plan the parent-child flow before building it. Keep the following in mind:

• Build the signal list before the loop that starts child automations — the Wait Signal action needs the complete list when it begins waiting.

• Each child automation must emit its signal with the correct Signal ID (typically the loop index) so the parent can match each response to the right entry.

• Always pass Waiting Instance ID and Waiting Instance Runtime Type from the callable trigger input into the child — do not hardcode these values.

• If a child automation might complete before the parent reaches the Wait Signal node, use the Long Wait variant for durability against timing gaps.

• Check the timeout flag in the step after the Wait Signal node to handle cases where not all children responded within the configured window.

Signals turn sequential batch processing into parallel fan-out — the setup cost pays off as soon as the number of parallel tasks grows large.