Asset Sensors

The sensor is called once per materialization event with the event details in asset_event.

Cross-Job Dependencies

Asset sensors enable dependencies across different jobs:

This pattern is useful when you have logically separate jobs that need coordination.

Cross-Code Location Dependencies

Asset sensors can monitor assets in different code locations:

The sensor can be in a different code location than the monitored asset.

Custom Evaluation Logic

Add conditional logic to control when to trigger:

Use cases for conditional logic: Trigger downstream processing only when data volume is sufficient, quality checks pass, or specific metadata conditions are met.

Triggering with Custom Configuration

Pass runtime configuration to the triggered job:

This allows you to propagate partition information or other metadata from the upstream asset to the triggered job.

Asset Sensors vs Declarative Automation

Use asset sensors when:

• Triggering imperative side effects (notifications, external API calls)
• Launching jobs with complex custom logic
• Cross-code location dependencies with conditional triggers
• Need to inspect materialization metadata before deciding to trigger

Use declarative automation when:

• Automating asset-to-asset execution within the same code location
• Defining dependencies based on asset freshness or missing status
• Requiring sophisticated dependency logic with composable conditions

Declarative automation is the recommended approach for asset-centric workflows. Asset sensors remain valuable for triggering actions outside the asset graph or when you need imperative control.