Execute Action Group
Execute Action Group dispatches several selected actions from one trigger, either all at once or in a configured order with a delay between submissions.
Build one trigger for several side effects
Use Execute Action Group when one event, manual command, or task pipeline step should start several actions together. It is useful for multi-channel alerts, combined operator commands, recovery procedures, and reusable action macros.
The group action dispatches other actions. It is not a transaction engine: it does not roll back completed actions, and sequential mode controls submission order rather than guaranteeing full completion before the next action starts.
Select the target actions
Use Actions to choose the actions that should be started by the group. Keep the list focused on actions that belong to one operational workflow.
Choose parallel or ordered dispatch
Keep Parallel execution enabled for independent actions. Disable it when order matters or when heavy actions should not start at the same instant.
Add delay only when useful
Use Execution delay (ms) in sequential mode to stagger expensive actions, external calls, or operator-facing notifications.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Title | Yes | Display name of the action group. Choose a name that describes the whole workflow, for example multi-channel alarm, camera recovery, or operator emergency command. | None |
Parallel execution | Yes | When enabled, all selected actions are submitted immediately. When disabled, target actions are submitted in list order with the configured delay between submissions. | Enabled |
Execution delay (ms) | Optional | Delay between sequential action submissions, in milliseconds. Visible when Parallel execution is disabled. Use values from 50 to 3600000 when a real delay is needed. | 0 |
Actions | Yes | Selected actions that should be dispatched by the group. Target actions must be running when the group invokes them. | None |
Dispatch actions as a grouped workflow
When the group is triggered, it sends the same execution context to every selected action. In parallel mode, selected actions are submitted to the system executor immediately. In sequential mode, actions are submitted in list order and the group waits only for the configured delay between submissions.
The group produces its own action event, and each target action can also produce its own action event. Event History can therefore show one group execution plus several child action executions.
Action fan-out
One trigger can start sound, email, SQL audit, forwarding, lifecycle actions, or custom actions without duplicating the same Event Manager rule.
Ordered dispatch
Sequential mode controls the order in which actions are submitted, not a strict wait-for-completion chain.
Shared context
All target actions receive the same context. Be careful when parallel actions read and write the same variables.
Use groups for alerting and recovery workflows
Fan-out notification
Use Parallel execution when one event should trigger several independent notifications at once, for example local sound, email, SQL audit, and forwarding to an external consumer.
Ordered side effects
Disable Parallel execution when actions should be submitted in a predictable order, for example write an audit record, wait briefly, then play a sound or send a message.
Staggered load
Use sequential mode with Execution delay (ms) when several heavy actions should not start at the same instant, such as scripts, SQL updates, file operations, or external HTTP calls.
Combined operator command
Create one manual action that starts or stops several tasks, restarts a connector, and sends an operator notification. This gives users a single button for a known recovery procedure.
Multi-channel alerting
Group local audio, email, and event forwarding so an important event reaches operators through several channels without duplicating the same rule in Event Manager.
Reusable action macro
Place common action chains into one group action and call it from multiple rules. This keeps rules smaller and makes future changes to notification behavior easier.
Delayed sequence with other actions
Combine the group with Timeout or lifecycle actions when a workflow needs "now and later" behavior, such as warn immediately and restart a source after a pause.
Operational notes
Parallel mode returns quickly
With Parallel execution enabled, all selected actions are submitted immediately. The group does not wait for every target action to finish before returning.
Sequential mode is ordered dispatch
With Parallel execution disabled, target actions are submitted in list order and the group sleeps for Execution delay (ms) between submissions, except after the last action. It is ordered dispatch, not a strict wait-for-completion chain.
Shared context can race
The same execution context is passed to every target action. Parallel actions that read and write the same context variables can observe different ordering from run to run.
Target actions must be running
Selected actions must be in running state when they are invoked. A stopped target action receives the call but will not perform its operation.
Action list is loaded on start
The selected Actions list is loaded when the group starts. Changing the selected actions restarts the group so the list can be rebuilt.
Child errors do not necessarily stop the group
Errors from individual target actions are handled as warnings by the group action and do not necessarily stop other submitted actions from running.
Use as a terminal pipeline action
When used inside a task pipeline, the group stops downstream processing after dispatching its actions. Place it at the end of a chain unless that behavior is intentional.
Avoid recursive groups
Do not create cycles where group A calls group B and group B calls group A. Such configurations can create unbounded action storms.
Use stronger orchestration when needed
For workflows that require transaction-like behavior, rollback, conditional branching, or exact completion results, use a Java action, a custom module, or an external orchestrator instead of a simple action group.