- Shipped
- September 17, 2026 at 12:30 AM UTC
- Author
- Kamo
- Commit
- 7545dc3
Drip campaigns start when something happens in the CRM, so the places that change leads and members now hand those events to EmailService's drip engine: - LeadHistoryService: a lead created (with how it arrived: by hand, imported, or from an integration or form), a status or sub-status change with both sides, and a reassignment from one team member to another. - **************** a pool lead claimed by spending a credit (paid or free-for-all), which records no lead history of its own. - MemberService: a member or team member account created. The platform mirror row is not a new member of the provider org and starts nothing. DripTriggerRecorder writes them to **************** which the engine drains. It only writes for an org whose ACTIVE drips listen for that kind (trigger or exit rule, read at most every 30s), hands over after the causing transaction commits, and writes on its own thread and connection, so a lead write can never fail or roll back because of a drip. A lead created Void (a test lead or a duplicate) is not someone to welcome. EmailCampaignEntity maps drip_id, drip_step_id and drip_cycle: a drip email sends through a hidden edition campaign per (step, cycle), so it keeps every send guarantee a campaign has. The columns and tables were applied by hand before this commit (emailservice ****************