Forward Event To Consumer
Forward Event To Consumer sends the current event to a selected event consumer, such as portal delivery, event history, file storage, a remote agent, or another integration.
Route selected events to the right destination
Use this action when an Event Manager rule, action group, or task pipeline should forward the current event to another Banalytics component. The selected consumer decides how to handle the event: deliver it to portal clients, store it, copy related files, or forward it to another agent or integration.
The action works best when upstream rules already filter the event stream. Forwarding every raw detector event can overload portal clients, event history, storage, or remote links.
Select the event consumer
Use Event consumer to choose the destination that should receive forwarded events, for example portal delivery, event history, file storage, or a remote agent connector.
Restrict accounts when needed
Use Forward to when the selected consumer supports account filtering and the event should be visible only to specific portal users or accounts.
Place after event-producing logic
Use the action in flows where an upstream task or Event Manager rule provides an event. Manual and scheduled runs create a simple status event for routing tests.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
Event consumer | Yes | Target consumer that should receive the event. The list contains active components that can accept events. | None |
Forward to | Optional | Target accounts for forwarding. The list is fetched from the selected consumer and is visible after Event consumer is selected. Leave empty only when unrestricted delivery is acceptable for that consumer. | None |
Forward the current event context
In normal event-driven execution, the action forwards the current event from the execution context to the selected consumer. If no event is present in the context, the selected consumer may receive an empty event value, so use this action where an upstream task or Event Manager rule provides an event.
When run manually or by schedule, the action creates a simple status event marked as manual or scheduled and forwards that event. This is useful for testing routing and account permissions before production rules depend on the action.
Event routing
The action does not transform the event. It sends the current event to the selected consumer and lets that consumer decide what to do with it.
Account filtering
Consumers that support account filtering use Forward to to restrict delivery. Portal permissions still apply.
Terminal action
The action stops downstream task processing after forwarding, so it usually belongs at the end of a chain.
Forward events for delivery, history, and replication
Portal event delivery
Select Portal WebRTC Integration when an Event Manager rule should deliver a non-system event to connected portal users. Use Forward to to restrict delivery to specific accounts when the event is not meant for every allowed operator.
Event history routing
Select Event History when a rule should explicitly store selected events in history. This is useful when only filtered, enriched, or business-important events should be persisted.
Remote agent forwarding
Select an agent connector consumer when events from one environment should be sent to another connected agent or upstream monitoring environment.
File replication workflow
Select File Storage for file-created flows when created files should be copied to another storage target. The file storage consumer ignores events that do not describe created files.
Account-specific notifications
Choose accounts in Forward to when only a subset of portal users should see an event, for example site-specific operators, maintenance users, or a customer account.
Manual or scheduled status delivery
Run the action manually or by schedule to create and forward a simple status event. This can be used to test routing and account permissions.
Event Manager fan-out
Combine this action with Execute Action Group when the same event should be forwarded to several consumers, such as portal delivery plus event history plus remote agent forwarding.
Operational notes
Use it with an event source
In normal execution, the action forwards the current event from the execution context. If no event exists, the consumer may receive an empty value.
Account routing is consumer-specific
Forward to is interpreted by the selected consumer. For portal delivery, selected accounts restrict delivery, while profile-owner connections and superusers can have broader delivery rights according to portal permissions.
Empty account selection can be broad
Leaving Forward to empty creates unrestricted delivery for consumers that support account filtering. Use explicit account selection when event visibility matters.
Routing rebuilds on restart
The action subscribes to the selected Event consumer on start. Changing the consumer or account selection restarts the action so routing can be rebuilt.
Some consumers suppress extra action noise
The action emits its own action result for most consumers, but avoids that extra action event when forwarding to Event History or Portal WebRTC Integration to reduce recursive event delivery noise.
Consumer must be running
The target consumer must be running and able to accept events. A stopped portal integration, storage, history, or remote connector may ignore the forwarded event.
Use as a terminal pipeline action
The action stops downstream task processing after forwarding, so place it as a terminal action unless stopping later tasks is intentional.
Avoid recursive routing
Be careful with routing rules that forward action events back into a consumer that triggers the same rule. Use narrow Event Manager filters to prevent loops.
Filter high-frequency events
For detector events, filter or batch before forwarding. Sending every raw motion, sound, or frame event can overload portal clients, event history, storage, or remote links.