Skip to main content

Alert propagation
App

The alert propagation app detects issue states on assets due to data quality or pipeline issues and propagates alerts as metadata to downstream assets. It runs as a workflow that evaluates scope, incident types, and propagation options to update custom metadata and optionally announcements. This reference provides complete configuration details for the Alert propagation app.

Configuration​

This section defines the fields required for workflow setup.

Workflow name​

Specifies a unique and descriptive name to identify the alert propagation workflow configuration in the Atlan interface. This name appears in the workflow list and helps distinguish it from other workflows. It's especially helpful when you run multiple alert workflows for different scopes or environments.

Example:

prod-alert-propagation-dq-and-pipeline

Qualified name operator​

Determines how the workflow matches asset qualified names to the value in Scope / qualified name prefix.

  • Equal: Matches assets whose qualified name is exactly the same as the value in Scope / qualified name prefix. Use this when you want to restrict the workflow to a single asset.
  • Not equal: Matches assets whose qualified name is anything other than the value in Scope / qualified name prefix. Use this to exclude a specific asset while processing everything else in the same environment.
  • Contains: Matches assets whose qualified name contains the value in Scope / qualified name prefix anywhere in the string. Use this when the identifying part of the qualified name might appear in the middle.
  • Doesn't contain: Matches assets whose qualified name doesn't contain the value in Scope / qualified name prefix. Use this to exclude all assets that share a common substring.
  • Starts with: Matches assets whose qualified name begins with the value in Scope / qualified name prefix. This is the most common choice when you scope propagation to a connection, database, or schema.
  • Pattern: Uses a pattern syntax (such as wildcard or regular expression, depending on configuration) to match qualified names. Use this for advanced matching when the other operators are too restrictive.

Scope / qualified name prefix​

Specifies the qualified name prefix of the assets from and to which the workflow propagates alerts. Only assets whose qualified names match this prefix (as interpreted by the Qualified name operator) are included in the workflow scope.

For example, you can:

  • Limit propagation to a specific connection, database, or schema.
  • Use a broad prefix to include all assets in your tenant.

Example (all assets in the tenant):

default/

Example (single connection scope):

default/snowflake/123456789/

Types of alerts and incidents​

Defines the specific incident categories for which the workflow propagates alerts. Only incidents whose type matches one of the values listed here are considered when applying alert tags and downstream metadata.

Use this field to:

  • Limit alert propagation to particular monitors or rule types (for example, only custom rules or only metric anomalies).
  • Exclude incident types that are noisy or not relevant for downstream consumers.

Values must be:

  • Quoted (single quotes) and comma-separated.
  • Valid incident type identifiers from your monitoring or incident management system.

Example:

'CUSTOM_RULE_ANOMALIES','METRIC_ANOMALIES'

In this example, the workflow processes only incidents classified as CUSTOM_RULE_ANOMALIES or METRIC_ANOMALIES and ignores all other incident types.

Alerts custom metadata set name​

Specifies the name of the custom metadata set used (or created) to store alert flags on impacted assets. The workflow writes alert state into this custom metadata set so that:

  • Downstream assets can display whether a data quality or pipeline issue affects them.
  • Dashboards and reports can filter or surface assets with active alerts.

If the named custom metadata set doesn't already exist, the workflow creates it with the appropriate attributes for alert tracking.

Propagation scope​

Controls which kinds of issues from your monitoring system drive downstream alert state: every alert and incident, or only formal incident records. Choose the value that matches how your monitoring tool classifies issues (some tools treat all issues as alerts; others distinguish low-severity alerts from high-severity incidents).

  • All alerts/incidents: The workflow propagates alerts for every supported issue type (for example, data quality anomalies and pipeline errors). Use this when you want the broadest coverage.
  • Only incidents: The workflow propagates only from objects that your monitoring tool treats as incidents, and ignores alert-only or informal states. Use this when your tool distinguishes alerts from incidents and you want downstream state to reflect only confirmed incidents.

Include announcements​

Determines whether the alert propagation workflow creates announcements in addition to custom metadata on impacted assets.

  • No: The workflow only updates tags and custom metadata. No announcements are created or updated.
  • Yes: The workflow also creates or updates announcements so that alert status is visible directly in the asset sidebar and lineage graph. Because announcements are shared across Atlan, enabling this can overwrite or remove existing announcements on the same assets if you use announcements for other purposes. If you are unsure whether announcements are used elsewhere, leave this set to No.

Include announcement confirmation​

Provides an explicit confirmation that you understand the risks of using announcements for alert propagation.

When Include announcements is set to Yes, this field is required. Setting an appropriate confirmation value acknowledges that:

  • Announcements created by the workflow may replace or remove other announcements on the same assets.
  • Announcements stay in sync with alert state and may change as incidents are created or resolved.

Example:

I understand that enabling announcements for alert propagation may overwrite existing announcements on impacted assets.

Max seconds to wait for propagation​

Specifies the maximum number of seconds the workflow waits between applying alert tags and updating downstream custom metadata and announcements. This delay gives Atlan's native tag propagation time to traverse lineage. As a result, downstream assets correctly reflect upstream alert state.

Typical configuration:

  • Default: 300 seconds (5 minutes), which is suitable for most environments.
  • Higher values: Useful if you have large or complex lineage graphs and you need propagation to complete before metadata is updated.
  • Lower values: Useful for smaller environments where propagation completes quickly and you want faster alert updates.

Example:

300

Fail workflow if tag propagation fails​

Controls how the workflow behaves if tag propagation or downstream update steps encounter errors.

  • No: The workflow logs the failure but continues or finishes without marking the overall run as failed. Use this when you prefer completion even if some tags or metadata couldn't be applied.
  • Yes: The workflow is marked as failed if tag propagation or downstream metadata updates don't succeed. Use this when reliable, end-to-end propagation is required and you want failures to be surfaced for investigation.

See also​