Triggers

A trigger is the event that causes an automation rule to fire. Each trigger is scoped to a specific entity via its trigger_id — for example, a particular form, a particular tag, or a particular pipeline stage.

Gordon CRM supports eight trigger types.

Entity-Based Triggers

These triggers fire when a contact interacts with a specific entity in the CRM.

"Any" option: Each entity-based trigger supports an "Any" option (e.g. "Any Form", "Any Event", "Any Tag", "Any Product") that fires the rule regardless of which specific entity was involved. This is useful for broad rules like "When any form is submitted → send notification."

Form Submitted

Context-Aware Double Opt-In

Gordon CRM uses a split processing model based on whether the submitter already exists in the workspace:

• New contact — The contact is created immediately, the submission is logged, and the automation fires right away in the form submission endpoint (/api/forms/[id]). No email verification is required because a brand-new email address has no prior data to protect.

• Existing contact — The submission is staged in a pending_form_submissions table with a secure token, and a verification email is sent. The automation only fires after the contact clicks the verification link (/api/forms/verify), which prevents impersonation attacks that could overwrite existing contact data.

Example use case: When someone submits the "Request a Demo" form → add the "Demo Request" tag.

Event Registration

This trigger fires from both event sources:

• Manual events — When a contact submits the public RSVP form, the automation fires after the registration record is created or re-activated.

• Eventbrite events — When the Eventbrite webhook handler (order.placed or attendee.updated) processes a registration, it also calls processAutomationTrigger with the CRM event ID. The handler deduplicates per-contact — if a single order contains multiple tickets for the same contact, the automation fires only once.

Note: For Eventbrite events, the trigger_id is the CRM event UUID (not the Eventbrite event ID). This means the same automation rule works regardless of whether the registration came through the native RSVP form or an Eventbrite webhook.

Example use case: When someone registers for "Spring Gala 2026" → enroll in the "Event Reminder" campaign.

See also: Events → Registration & Public Pages for the full registration flow, and Events → Eventbrite Integration for webhook processing details.

Product Purchase

Example use case: When someone purchases "Annual Membership" → add the "Member" tag.

Tag-Based Triggers

These triggers fire when a tag is added to or removed from a contact. They can be caused by manual user action or by a preceding automation action.

Tag Applied

Example use case: When "VIP" tag is applied → enroll in the "VIP Welcome Sequence" campaign.

Tag Removed

Example use case: When "Active Member" tag is removed → remove from the "Members-Only Newsletter" campaign.

Deal Triggers

These triggers fire when a deal progresses through a sales pipeline. Both use a cascading pipeline → stage/status picker in the UI.

Deal Stage Changed

The UI uses a two-tier picker: first select a pipeline (or "Any Pipeline"), then select a stage within that pipeline (or "Any Stage").

Example use case: When a deal moves to the "Proposal Sent" stage → add the "Proposal Sent" tag.

Deal Status Changed

The UI uses a two-tier picker: first select a pipeline (or "Any Pipeline"), then select a status (Won, Lost, or "Any Status").

Example use case: When any deal is marked as "Won" → send notification to the sales manager.

Lifecycle Triggers

Contact Birthday

Unlike other triggers, this one does not require a specific entity to be selected in the UI — it fires globally for all contacts in the workspace whose birth_month and birth_day fields match the current date.

Example use case: On a contact's birthday → enroll in the "Birthday Greeting" campaign.

Trigger Resolution

When a trigger fires, the engine resolves human-readable names for display purposes: