Workflow Trigger Processing#

Overview#

The WorkflowManager handles two fundamentally different code paths for triggering workflows: one for alert events and one for incident events. They differ significantly in how conditions are evaluated and how workflows are selected.

Alert Triggers: insert_events()#

Alert-triggered workflows go through WorkflowManager.insert_events(), which:

1. Fetches all enabled tenant workflows from the store.
2. For each workflow, iterates over its triggers and skips any that are not type alert 1.
3. Evaluates CEL conditions against the alert payload 2:
   • Legacy filters format is first converted to a CEL expression via _convert_filters_to_cel() 3.
   • The source field receives special handling: source == "x" is rewritten to source.contains("x") because source is a list 4.
   • Severity strings are normalized to numeric order values before CEL evaluation 5.
   • CEL is preprocessed via preprocess_cel_expression() for additional normalization 6.
4. If the trigger has neither filters nor cel, the workflow runs unconditionally 7.
5. After CEL passes, checks only_on_change and severity_changed guards against the previous alert 8.
6. Enriches the alert from the DB before enqueuing 9.
7. Appends to scheduler.workflows_to_run under a threading lock 10.

Entry points that call insert_events():

• Single-alert enrichment via _enrich_alert() when status changes.
• Bulk enrichment via batch_enrich_alerts().

Incident Triggers: insert_incident()#

Incident-triggered workflows go through WorkflowManager.insert_incident(), which:

1. Fetches all tenant workflows (no exclude_disabled flag — disabled workflows are filtered inline) 11.
2. Collects all event strings from triggers of type incident: e.g., "created", "updated", "deleted" 12.
3. Checks if the incoming trigger string is in that list — no CEL evaluation occurs 13.
4. Applies any stored incident enrichments to the IncidentDto before enqueuing 14.
5. Appends to scheduler.workflows_to_run 15.

Missing CEL Evaluation in insert_incident()#

Unlike alert triggers, incident triggers have no CEL filter support. Any cel or filters key in an incident trigger definition is silently ignored — the workflow fires for all incidents of that event type. This is a known gap: users cannot filter incident-triggered workflows by incident properties (e.g., severity, name, or custom enrichment fields).

Entry points that call insert_incident() via IncidentBl.send_workflow_event():

PR #5254 (open) adds an alert_association_changed event that fires when alerts are linked/unlinked from an incident, and also populates incident.linked_alerts as a formatted list for use in workflow actions.

Known Bug: Incident Enrichment Fails in foreach Loops#

When an incident-triggered workflow iterates over a list (e.g., foreach: "{{ incident.services }}") and an action tries to enrich_incident, the enrichment fails with "No fingerprint found for alert enrichment". 20

Root cause (base_provider._enrich()): The foreach_context branch is entered first (line 212) because the loop value is a truthy string. The code then falls through all isinstance checks and reaches else: fingerprint = None, never reaching the incident_context branch at line 245. Fix: add a self.context_manager.incident_context check inside the foreach branch before the final else.

Key Files#