Automations
Gordon CRM includes a unified automation engine that lets you connect triggers (things that happen) to actions (things you want to do in response). Automations eliminate repetitive manual work and ensure every lead, registrant, or customer is handled consistently.
How It Works
Every automation rule has three parts:
- Name — A human-readable label for the rule (e.g. "Tag VIP on form submit").
- Trigger — The event that starts the automation (e.g. a form is submitted, a deal moves to a new stage).
- Action — What Gordon CRM does automatically in response (e.g. add a tag, enroll in a campaign).
When a trigger fires, the engine queries all active rules that match the trigger_type and trigger_id,
then executes each matching action for the contact involved.
Trigger fires → Engine queries matching active rules → Actions execute per-contactArchitecture
Automations are powered by a single server-side function — processAutomationTrigger — that is called from every
part of the application where triggerable events occur:
| Caller | Trigger Type |
|---|---|
Form submission endpoint (/api/forms/[id]) | form_submission (new contacts) |
Form verification endpoint (/api/forms/verify) | form_submission (existing contacts) |
RSVP endpoint (/api/rsvp/[id]) | event_registration |
Eventbrite webhook handler (/api/webhooks/eventbrite) | event_registration |
Stripe webhook handler (/api/webhooks/stripe) | product_purchase |
| Contact tag operations (server actions) | tag_applied, tag_removed |
| Deal stage/status updates (server actions) | deal_stage_changed, deal_status_changed |
Birthday cron sweeper (/api/cron/birthday-sweeper) | contact_birthday |
This centralized design means that new triggers can be added without changing the core engine logic — only a new
call to processAutomationTrigger is needed at the point where the event originates.
The Automation Rule Model
Each automation rule is stored in the automations table:
| Column | Type | Description |
|---|---|---|
id | uuid | Primary key |
workspace_id | uuid | Tenant isolation — rules belong to a single workspace |
name | text | Human-readable name shown in the UI |
trigger_type | text | One of the eight supported trigger types |
trigger_id | text | The specific entity that fires the trigger (form ID, tag ID, stage ID, etc.) |
action_type | text | One of the four supported action types |
action_id | text | The target entity for the action (tag ID or campaign ID) |
is_active | boolean | Toggle to enable/disable without deleting |
created_at | timestamptz | When the rule was created |
updated_at | timestamptz | When the rule was last modified |
RBAC
Automations are classified as structural data in Gordon CRM's role-based access control model:
- Owner & Admin — Can create, edit, toggle, and delete automation rules.
- Member — Can view automation rules but cannot modify them.
Where Automations Are Managed
Automation rules appear in two places within the dashboard:
-
Automations page (
/automations) — The central hub for tag-based rules (add tag, remove tag). Campaign-related rules are excluded from this view because they are managed directly on each campaign. -
Campaign detail page (
/campaigns/[id]) — Entry and exit automations for drip sequences. These rules use theenroll_campaignandremove_campaignaction types and are tightly coupled to campaign lifecycle management.
Next Steps
- Triggers — All eight trigger types and how they fire.
- Actions — The four action types and their behavior.
- Loop Protection — How cascading rules are kept safe.