This is an automated email from the ASF dual-hosted git repository.
o-nikolas pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new 6cb5d040088 Add docs for multi-team triggerer support (#67608)
6cb5d040088 is described below
commit 6cb5d0400884d3788f3182153cbe7cfd027ad839
Author: Ramit Kataria <[email protected]>
AuthorDate: Wed Jun 3 16:15:03 2026 -0700
Add docs for multi-team triggerer support (#67608)
* Add docs for multi-team triggerer support
Add a `Team-scoped Triggerer` section to the multi-team documentation
covering the `--team-name` CLI argument, behavior for team-scoped vs
global triggerers, interaction with `--queues`, and an example deployment.
Add a tip in the deferring docs pointing users toward `--team-name` as
the native multi-team solution alongside the existing `--queues` docs.
Remove `Async support` from the `Work in Progress` list since team-scoped
triggerer support is now implemented/in PR.
---
.../docs/authoring-and-scheduling/deferring.rst | 8 ++++
airflow-core/docs/core-concepts/multi-team.rst | 45 +++++++++++++++++++++-
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/airflow-core/docs/authoring-and-scheduling/deferring.rst
b/airflow-core/docs/authoring-and-scheduling/deferring.rst
index 62f5d0b0158..0e54a9ca593 100644
--- a/airflow-core/docs/authoring-and-scheduling/deferring.rst
+++ b/airflow-core/docs/authoring-and-scheduling/deferring.rst
@@ -494,6 +494,14 @@ Under some circumstances, it may be desirable to assign a
Trigger to a specific
* In a multi-tenant Airflow system where you run a distinct set of
``triggerers`` per team.
* Running distinct sets of ``triggerers`` hosts, where each set of hosts are
configured for different trigger operations (e.g. each set of triggerers may
have different cloud permissions).
+.. tip::
+
+ If you are using :doc:`Multi-Team mode</core-concepts/multi-team>`, the
``--team-name`` option provides
+ native team-scoped triggerer assignment for all trigger types
(task-created, event-driven, and callback).
+ See :ref:`Team-scoped Triggerer <multi-team-triggerer>` in the Multi-Team
documentation.
+ The ``--queues`` option described below is an older, queue-based mechanism
that can be combined with
+ ``--team-name`` if needed.
+
To enable queue assignment for triggers, do the following:
1. Set the :ref:`config:triggerer__queues_enabled` config value to ``true``.
This will ensure when tasks defer, they pass their assigned task queue to the
newly registered trigger instance.
diff --git a/airflow-core/docs/core-concepts/multi-team.rst
b/airflow-core/docs/core-concepts/multi-team.rst
index eb6371701b6..dd964961910 100644
--- a/airflow-core/docs/core-concepts/multi-team.rst
+++ b/airflow-core/docs/core-concepts/multi-team.rst
@@ -65,6 +65,7 @@ Teams are associated with Dags through **Dag Bundles**. A Dag
bundle can be owne
- All Dags within that bundle belong to that team
- Tasks in those Dags inherit the team association
- All Callbacks associated with those Dags also inherit the team association
+- Triggers created by those Dags' tasks inherit the team association
- The scheduler uses this relationship to determine which executor to use
.. note::
@@ -503,6 +504,49 @@ When Multi-Team mode is enabled, the scheduler performs
additional logic to dete
teams share the same metadata database and common Airflow infrastructure.
For absolutely strict security
requirements, consider separate Airflow deployments.
+.. _multi-team-triggerer:
+
+Team-scoped Triggerer
+---------------------
+
+When Multi-Team mode is enabled, a triggerer should be scoped to each specific
team using the ``--team-name`` CLI argument. A team-scoped triggerer processes
deferred tasks (triggers) belonging to that team's Dags. This allows teams to
run isolated triggerer instances with independent capacity and failure domains.
+
+Configuration
+^^^^^^^^^^^^^
+
+Start a team-scoped triggerer by passing ``--team-name``:
+
+.. code-block:: bash
+
+ # Triggerer for team_a only
+ airflow triggerer --team-name team_a
+
+ # Triggerer for team_b only
+ airflow triggerer --team-name team_b
+
+ # Global triggerer — processes triggers from Dags with no team association
+ airflow triggerer
+
+Startup validation ensures that ``core.multi_team`` is enabled and the
specified team exists in the database.
+
+Behavior
+^^^^^^^^
+
+- **Team-scoped triggerer** (``--team-name team_x``): Only picks up triggers
whose originating Dag belongs to a bundle mapped to ``team_x``.
+- **Global triggerer** (no ``--team-name``): Only picks up triggers whose
originating Dag belongs to a bundle with no team assignment.
+- **Multi-Team disabled** (``core.multi_team = False``): ``--team-name`` is
rejected. No filtering occurs and all triggerers process all triggers (existing
behavior).
+
+Interaction with ``--queues``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Team filtering and queue filtering are orthogonal — they combine as AND
conditions. For example, a triggerer started with ``--team-name team_a --queues
q1,q2`` only processes triggers that both belong to ``team_a`` and were
deferred from tasks in queues ``q1`` or ``q2``.
+
+.. note::
+
+ Ensure that at least one triggerer is running for every team, otherwise
that team's triggers will
+ remain unassigned until one starts — the same applies to every queue when
``--queues`` is used. If you
+ combine ``--team-name`` and ``--queues``, this requirement extends to each
team-and-queue combination.
+
.. _multi-team-asset-event-filtering:
Team-Based Asset Event Filtering
@@ -673,7 +717,6 @@ Work in Progress
Multi-Team mode is currently an experimental feature in preview. It is not yet
fully complete and may be subject to changes without warning based on user
feedback. Some missing functionality includes:
- Dimensional metrics by team
-- Async support (Triggers, Event Driven Scheduling, async Callbacks, etc)
- Some UI elements may not be fully team-aware
- Full provider support for executors and secrets backends
- Command and Secrets based lookup for team based configuration
