Automated Trigger Rules

Overview

A trigger rule is a "when this event happens, do this" rule that runs in the background without anyone pressing a button. The supported trigger sources map directly to the RabbitMQ queues the platform already publishes to:

Event	Queue
A member joins or leaves an audience	audience_membership_trigger
Someone submits a form	form_submitted_trigger
Someone clicks a campaign link	campaign_click_trigger
An inbound message arrives	message_received_trigger
A booking is created or changes status	booking_event_trigger

This module covers only the authoring side — defining rules and reviewing their statistics and execution history. The actual execution happens in the line-management-worker-go service. Trigger rules are also the foundation that Workflow & Chatbot builds on, since every workflow must be bound to a trigger rule to have a starting point.

Business Flow

1. Load available events — GET /api/trigger-rules/dropdown returns the selectable trigger sources, cached in Redis under the key TRIGGER_SOURCE_TYPES.
2. Create a rule — POST /api/trigger-rules where the user picks a source event, its conditions, and the action to perform.
   • The service calls validateReferences (raw SQL) to confirm the referenced audience, form, or campaign actually exists. If any reference is missing, the request fails with a cause payload identifying the bad reference.
3. List rules — GET /api/trigger-rules returns a paginated list. Each row carries execution stats (run count, successes, failures) computed with a per-row subquery.
4. Check dependencies — GET /api/trigger-rules/by-audience/:audienceId lists every rule bound to a given audience. This powers the warning shown before an audience is deleted.
5. Manage a single rule — GET /api/trigger-rules/:id for details, PUT /api/trigger-rules/:id to edit, and DELETE /api/trigger-rules/:id to remove.
6. Monitor results — GET /api/trigger-rules/:id/stats returns a summary (raw SQL), and GET /api/trigger-rules/:id/logs returns the paginated per-execution history from the trigger_log table.
7. Runtime side — When an event fires, the worker reads the rules from Redis (TRIGGER_RULES), takes TRIGGER_LOCK to prevent overlapping runs, executes the configured action, and writes the outcome to trigger_log.

Key Files & Functions

The code lives in internal/modules/triggerrule/, made up of controller.go, service.go, and dto.go.

Method	Route	Handler	Policy
GET	/api/trigger-rules	ct.findAll	read trigger-rule
GET	/api/trigger-rules/dropdown	ct.getDropdown	read trigger-rule
GET	/api/trigger-rules/by-audience/:audienceId	ct.findByAudienceID	read trigger-rule
GET	/api/trigger-rules/:id	ct.findOne	read trigger-rule
GET	/api/trigger-rules/:id/stats	ct.getStats	read trigger-rule
GET	/api/trigger-rules/:id/logs	ct.getLogs	read trigger-rule
POST	/api/trigger-rules	ct.create	create trigger-rule
PUT	/api/trigger-rules/:id	ct.update	update trigger-rule
DELETE	/api/trigger-rules/:id	ct.delete	delete trigger-rule

Every route is wrapped with modulegate.ModuleGate(d, "trigger-rule").

Connections to Other Services

• Access control — All routes pass through ModuleGate("trigger-rule"), with PolicyModuleTriggerRule supplied as policy metadata.
• Tables — trigger_rule, trigger_log, audience, form_builder, campaign, workflow
• Redis — TRIGGER_RULES (rule set consumed by the worker), TRIGGER_SOURCE_TYPES (dropdown cache), TRIGGER_LOCK (overlap guard)
• RabbitMQ — Consumes audience_membership_trigger, form_submitted_trigger, campaign_click_trigger, message_received_trigger, and booking_event_trigger; dispatches outbound work through web_request_execute.
• Executor — line-management-worker-go performs the actual rule execution.
• Related modules — Workflow, Audience Management, Form Builder, Campaign Management, and the Appointment Booking App.