Worker Bees run actions when platform events occur. Viewing them requires workerbees:read:automations or workerbees:admin:automations; creating them requires workerbees:admin:automations and any permissions required by their actions.
Create a Worker Bee
- Open Worker Bees, then New Worker Bee.
- In Trigger, enter a name, optional description and one or more events. Selecting several events creates a separate Worker Bee for each, sharing the configuration.
- In Filter, choose Single set for standard actions or Swarm for ordered branches. Read the current filter limitation below before adding conditions.
- In Actions, choose Add action, select an available action and complete its fields. Actions come from the workspace’s enabled modules and integrations; options can be unavailable when your trigger cannot supply the record they need.
- Use Insert data on supported text fields to include values from the triggering event. If you chose several different events, check that every event supplies those values; otherwise create separate configurations.
- In Review, check the events, conditions and actions, then Create worker bee. Newly created bees are active.
Changing an action selection clears its previous inputs. An incomplete badge means required inputs still need attention; the wizard cannot finish until the available actions are configured.
Current filter limitation
The visual builder’s filter conditions are not currently compatible with the event matcher. A bee with conditions created there can remain active without firing; the same limitation affects conditioned swarm branches. Do not rely on these conditions for a live automation. Ask your administrator to validate a filtered configuration through the Worker Bees API before use.
An unfiltered bee runs for every matching event. Use it only when that is the behaviour you intend; removing a filter broadens the automation.
Standard actions and swarms
Standard mode runs all configured actions. A swarm chooses the first matching branch and runs its actions. A branch with no conditions always matches, so place a fallback last; otherwise later branches cannot run. The filter limitation above applies before relying on a conditioned branch.
Contact messages may require recorded consent for the selected purpose and channel. A transactional option skips that consent check but still refuses contacts recorded as children or deceased. Check the action’s fields and permissions rather than assuming every message can be sent.
Check flight history
Click a Worker Bee’s row to open its flight history. Each row shows success/failure, triggering event, action type, start time and duration. Use the page controls to browse earlier flights and retry loading if the list fails.
If no flight appears, check that the bee is active, the selected event actually occurred and there are no unsupported visual filters. For failed flights, check action inputs, destination configuration, consent and permissions. Give support the bee name and failure time if the cause is unclear.
The current list/history screens do not offer editing, pausing, deletion or a manual replay button. Administrators can use the API’s supported management operations. Last Run alone is not proof that every action succeeded.