Dynamic Routing Tables

When using dynamic routing, you need to define the routing table with the dimensions and tags which are used to direct the alert to specific channels or users. These routing tables are CSV based files which contain three columns:

  • The dimension or tag value by which the routing is done.
  • The email or channel name to which the alert will be sent.
  • The channel type (see the list below)

Dimension or tag value

This is the Anodot input field (dimension or tag)

Channel name

This is the destination channel name

Channel type

This is the destination channel type

USAAnodot_alerts; USA_alertsSlack
CanadanoCEmail
UKJohnTamTam
UK[email protected]Email address

Note the following when defining your routing table:

  1. The dynamic routing table must be in CSV format, and consist of three columns with a maximum of 10,000 rows.

  2. The Anodot API can also be used to upload and edit dynamic routing tables.

  3. Header line is mandatory (as opposed to previous versions of dynamic routing tables).

  4. Existing data from legacy routing table files without headers that are already uploaded to the system will support email only; this data will be automatically converted by Anodot to the new format

  5. The channel has to exist before uploading the file. If you attempt to upload a file referring to a channel name which hasn't been created yet - the upload will fail. Possible channel types can be viewed below and in Anodot's API documentation .

  6. The channel name is case-sensitive and should be identically matched to avoid upload failures.

  7. The channel type for direct emails is ‘Email address’. Note the difference between email and email address. email is an email channel (as defined in the Channels management page) and email address is a specific email address. You may use several emails separated by a semi-colon (;).

  8. To ensure you can still route the alert to someone even if the dimension value in the metric is not found, you can define a NOT_FOUND value in the dynamic routing table. As a result, when a dimension value is not found in the routing table file AND the NOT_FOUND entry exists, the alert is sent to the recipient in the {NOT_FOUND} line, as shown below.

    Dimension or tag valueChannel nameChannel type
    {NOT_FOUND}[[email protected]]email address


Channel types

Use the exact string in the type column according to your needs.

TypeDescription
emailSend alerts to an email distribution list
Email addressSend to a specific email address specified in the file
WebhookSend the alert as a JSON object to a webhook server
slackappUse Anodot's Slack app to handle the alerts (new)
slackPost the alert as a Slack message (Legacy)
pagerdutyCreate an event in a PagerDuty service
jiraOpen the alert as ticket in a JIRA project
opsgenieCreate an OpsGenie alert
msteamsPost the alert as an MS Teams message
tamtamSend the alert as a TamTam message
mattermostCreate a Mattermost message
snsSend alerts as AWS SNS messages
telegramSend alerts as Telegram messages
servicenowSend alerts to ServiceNow
salesforceCreate a Salesforce case from an alert

Attached to this article are sample CSV files where the dimension is country and according to the country, the alert is routed to a channel. The first one (multiple channels.csv) uses multiple channels types and the second uses (histbycountrymultiple.csv) multiple mails per dimension value.

📎 hitsbycountrymultiple.csv

📎 multiple channels.csv


Did this page help you?