Actions

An action is what Gordon CRM does automatically when a matching trigger fires. Each action targets a specific entity via its action_id — either a tag or a campaign.

Gordon CRM supports seven action types, split into five categories.

Tag Actions

Tag actions modify a contact's tags. These are the most common automation actions and appear on the central Automations page (/automations).

Add Tag

After a tag is successfully added, the engine fires a cascading tag_applied trigger for the newly added tag. This enables chaining — for example, adding tag A can trigger a rule that enrolls the contact in a campaign.

Form submitted
  → Action: Add "VIP" tag
     → Cascading trigger: "VIP" tag applied
        → Action: Enroll in "VIP Welcome" campaign

Important: Cascading tag triggers increment an internal depth counter. If the depth exceeds 3, the chain is terminated to prevent infinite loops. See Loop Protection.

Remove Tag

After a tag is successfully removed (confirmed by checking the return value), the engine fires a cascading tag_removed trigger. This allows exit workflows — for example, removing a "Member" tag can unenroll a contact from member-only campaigns.

Campaign Actions

Campaign actions manage a contact's enrollment in drip sequence campaigns. These rules are managed on each Campaign detail page (/campaigns/[id]) and are excluded from the central Automations page.

Enroll in Campaign

The enrollment process includes multiple safety checks:

1. Active enrollment check — If the contact already has an active or processing enrollment in the same campaign, the action is skipped entirely.
2. Trigger event dedup — If a triggerEventId is provided (e.g., from an event registration), the engine checks for a prior completed enrollment with the same trigger event ID. This prevents webhook retries from re-enrolling contacts.
3. Campaign status check — The campaign itself must be in active status. Draft or paused campaigns will not accept new enrollments.
4. Step calculation — The campaign engine's calculateNextCampaignStep function determines when the first email should be sent based on delay offsets and event dates. If all steps are in the past (late enrollee), the enrollment is immediately marked as completed.

Remove from Campaign

This is typically used as part of an exit criteria workflow on the campaign detail page — for example, "When the contact is tagged as 'Unresponsive' → remove from this campaign."

Where Actions Are Managed

This split keeps the UI focused — marketers manage campaign enrollment rules alongside the campaign itself, while system-level tag automations, task creation, and notification rules live in a central hub.

Task Actions

Task actions automatically create to-do items in response to triggers. These rules are managed on the central Automations page (/automations).

Create Task

Unlike tag and campaign actions — which point action_id at a pre-existing entity (a tag or campaign) — the create_task action has no pre-existing entity to reference. The task doesn’t exist until the automation fires.

Inline action_config

When action_type = 'create_task', the action_config JSONB column stores the task blueprint:

{
  "title": "Follow up with new lead",
  "description": "Review form submission and send intro email",
  "assigned_to": "user-uuid-or-null",
  "due_offset_hours": 48
}

Why inline config instead of task templates? A task template table would require its own CRUD surface, RLS policies, and navigation entry — all for something used rarely. Inline action_config on the automation rule itself keeps the design simple with zero new tables. Users who need the same task config on multiple rules can manually recreate the rule with the same settings.

Contact and Deal Linking

When the automation fires:

• Contact is always auto-linked from the trigger’s contactId (every trigger provides a contact context).
• Deal is auto-linked from the trigger context when available (e.g. deal_stage_changed triggers).
• Due date is calculated as trigger_time + due_offset_hours.

UI Form

When a user selects "Create Task" as the action type on the Automations page, the standard entity picker is replaced with an inline form:

Action Entity Resolution

When displaying rules in the UI, the engine resolves action_id values to human-readable names:

Agreement Actions

Agreement actions dispatch digital agreements to a contact for signing.

Send Agreement

Dedup Behavior

The dispatch service applies the same dedup logic as manual sending:

UI Form

When a user selects "Send Agreement" as the action type on the Automations page, the standard entity picker is replaced with a template dropdown listing all active agreement templates. If no active templates exist, italic helper text reads: "No active templates. Create one in Settings → Agreement Templates."

See Agreements for full documentation on template management and the signing flow.

Notification Actions

Notification actions send internal email alerts to workspace members (and optionally external recipients) when a trigger fires. These are managed on the central Automations page.

Send Notification

Inline action_config

When action_type = 'send_notification', the action_config JSONB column stores the recipient configuration:

{
  "member_ids": ["user-uuid-1", "user-uuid-2"],
  "external_emails": ["partner@example.com"]
}

At least one recipient (member or external) is required.

What the Email Contains

Notification emails automatically include:

• Contact details — The name and email of the contact who triggered the automation.
• Trigger context — Which trigger fired (e.g. "Form submitted: Request a Demo").
• Deal enrichment — When triggered by a deal event (deal_stage_changed or deal_status_changed), the email also includes the deal name and deal value (formatted as currency).

UI Form

When a user selects "Send Internal Notification" as the action type on the Automations page: