{% load common_extras %} {% comment %} SPEC §10's rule trigger: an internal event, an optional id filter for the thing the event is about, and an optional §11.4 condition on the contact. The two filters are not the same question and the panel says so. `tag_id` is "the tag that was just added"; the condition bar below is "and the contact looks like this afterwards". A condition document cannot express the first — the closest it gets is "somebody who now has VIP", which fires when any tag at all is added to a VIP — so the id filter is its own control. The condition bar is `contacts/_filter_bar.html` unchanged, rendered from the same `filter_config` payload the CRM's list page uses. Its Alpine factory is defined by the hosting page (flows/edit.html includes the script), because an htmx-swapped fragment cannot define an x-data factory for itself. {% endcomment %}

Fires for the tag that changed. Adding a tag a contact already has changes nothing and fires nothing.

Use the conditions below to match the field's new value.

Only when the contact matches

{% include "contacts/_filter_bar.html" with filter_embedded=True %}

Checked after the change, so a rule can ask what the contact looks like now. Leave empty to fire for everyone. Each contact can start this flow at most once a minute.