Triggers and conditions

triggers decide when an automation rule should run conditions narrow a trigger so the rule only runs for the events you care about peach events peach events come from activity inside peach, such as conversations, messages, templates, lists, and flows use peach events when the automation should react to something peach already tracks integration events connected integrations can expose their own trigger events use these when an external system should start a peach automation, but the integration already has a registered event source in peach custom developer api the full automation editor supports two custom api styles style use it when automation endpoint the payload is meant for one specific automation rule topic mapped payload multiple rules may listen to a shared event topic the direct automation endpoint is generated after the rule is saved topic mapped payloads are posted to the general events endpoint and must include a topic value that matches the rule's topic condition condition variables some triggers ask for condition variables these are the values peach uses to decide whether the incoming event matches for example a template message trigger can filter by template or message status a custom topic trigger can filter by topic name leave optional filters blank when the rule should match any value for that field payload mappings payload mappings tell peach where to find important data inside an event payload common mappings include recipient name recipient phone number recipient email template variables deduplication keys mappings are especially important for custom api automations and template sending automations advanced triggers use advanced triggers when a rule needs multiple triggers, exit triggers, or custom data mappings beyond the simple builder advanced triggers are managed from the rule's trigger screen or visual editor context pipeline specific triggers such as item enrolled, stage changed, completed, or dropped off are covered in pipeline automations #