Dynamic dispatch with external data

Why dynamic dispatch

In enterprise operations, you often manage thousands of monitored objects (hosts, services, databases, etc.), and the responsible responders change frequently as the organization evolves. Maintaining separate escalation rules for each object is both costly and error-prone. Dynamic dispatch solves this problem: you configure a single escalation rule as a “template”, and the system automatically replaces the notification targets based on specific labels carried by the alert. This way, whenever responders change, you only need to update the label data — no need to modify the escalation rule itself.

How it works

The core flow of dynamic dispatch consists of three steps:

Alert enters the channel

After being ingested through an integration, the alert enters a channel and matches a configured escalation rule.

System reads dynamic labels

The system detects that the alert carries a specific label (e.g., layer_person_reset_0_emails=bob@corp.com) and automatically replaces the notification targets in level 1 of the escalation rule with Bob.

Dispatch based on the updated rule

The system dispatches notifications according to the updated escalation rule. After dispatch completes, these control labels are automatically removed to keep the alert details page clean.

Dynamic dispatch does not work independently — it depends on an existing escalation rule in the channel. You need to configure an escalation rule in advance as a “template”. Dynamic labels only replace the notification targets (responders, teams, or chat bot) within the rule; other settings (notification methods, timeout, escalation levels, etc.) remain unchanged.For the full label parameter reference, see Dynamic dispatch.

How to generate dynamic labels

The key to dynamic dispatch is ensuring alerts carry the correct labels. The following two approaches can achieve this — choose whichever fits your situation.

Approach 1: Add labels directly in the monitoring system

If you have configuration access to your monitoring system and it supports custom labels (e.g., Prometheus, Nightingale, Zabbix), simply add the label to your alert rules:

Label key: layer_person_reset_0_emails
Label value: bob@corp.com

This approach requires minimal configuration and works well when responders rarely change. However, you’ll need to update the alert rules in your monitoring system whenever personnel changes occur.

Approach 2: Auto-generate via label mapping

If you cannot modify the monitoring configuration, or prefer to centrally manage the “monitored object → responder” mapping (e.g., synced from a CMDB, configuration platform, or any external data source), use the label mapping feature. This approach creates a mapping table that automatically “translates” existing basic labels in alerts (such as host) into dynamic dispatch labels, without modifying the monitoring system.

Prepare mapping data

Compile the mapping between monitored objects and responders. For small datasets, you can enter data manually on the page; for large datasets, prepare a CSV file.

The target column name in the CSV must use the dynamic dispatch parameter name (e.g., layer_person_reset_0_emails).

host (source label)	layer_person_reset_0_emails (target label)
web-server-01	bob@corp.com
db-server-02	alice@corp.com

You can source this data from anywhere — CMDB, configuration management platforms, operations systems, or Excel spreadsheets — as long as it follows the format above.

Create a mapping table

Import the data into the system to create a reusable mapping “dictionary”.

Go to Integration Center → Label Mapping.
Click Create Label Mapping.
Enter data:
- Upload file: Upload a CSV file for bulk operations.
- Manual input: Add entries one by one on the page for small-scale maintenance.
After saving, you’ll have a mapping table ready to be referenced by integrations.

To keep the mapping in sync with external systems in real time, use the Flashduty API to update the mapping table automatically, achieving fully unattended configuration sync.

Configure label enhancement rules

Reference the mapping table in your alert integration so the system automatically populates dynamic labels during alert ingestion.

Go to Integration Center → Label Enhancement.
Find your target alert integration (e.g., Zabbix integration) and open its details.
Select the Label Enhancement tab, and set the action type to Label Mapping.
Select mapping table: Choose the mapping table created in the previous step.
Configure mapping:
- Source label: Select host.
- Target label: Select layer_person_reset_0_emails.

Once configured, the system will automatically look up the host value in the mapping table during alert ingestion and generate the corresponding dynamic dispatch label.

Configure a template escalation rule

Configure an escalation rule in the target channel. The notification targets in this rule can be set to any value (e.g., a default team) — it serves only as a “template”. During actual dispatch, the notification targets will be replaced by the dynamic labels.Other settings in the rule (notification methods, timeout escalation, etc.) will function normally.For detailed configuration, see Escalation rules.

Verify the result

After completing the configuration, trigger a test alert to verify:

Check the dispatch process: In Incident Details → Timeline, you’ll see a log entry similar to: “Based on dynamic labels, responders have been reset to bob@corp.com”.
Check alert labels: On the alert details page, you will not see layer_person_reset_xxx labels — these control directives are automatically cleaned up after taking effect.