Skip to main content
Triggers are the “when” of your automation. They listen for specific events in Custral and start the workflow execution.

​
Event-Driven Triggers

​
Data Changes

  • Record Created: Fires immediately when a new record is added to a specific Object.
  • Property Updated: Fires when a specific property on a record is updated. You can filter it to only fire when the property is set to a specific value.

​
Usage

  • Usage Changed: Fires when a record’s usage property rises to at least a number, falls below one, or drops by a percentage against the period before. Pick the object, the usage property to watch, the condition and the number. A drop can also take a minimum previous usage, so a record that went from 2 uses to 0 is not treated as a 100% drop. It is checked once a night rather than per event, because a usage figure moves on its own: a new event arrives, or the rolling window’s edge sweeps past an old one. It fires on the move into the condition, not on the condition holding, so a record that stays below a threshold for a month fires once and fires again only after it has climbed back out and fallen through a second time. Turning a trigger on fires it for later crossings only, never for every record already past the number.

​
Lists

  • Joins a List: Fires when a record joins a list, including a smart list it starts matching. Each record fires once per trigger, so a company that leaves and rejoins is not enrolled in the same sequence twice. Include records already in the list decides what happens when you turn it on: off (the default) starts only the records that join from then on; on also starts everyone already in it.
  • Leaves a List: Fires when a record that was in the list is no longer in it, including a smart list it stops matching or a record that was deleted. It fires every time a record leaves. Use it as a sequence’s exit goal, for example to stop onboarding emails once a company is no longer in Onboarding. Both are checked every 15 minutes rather than instantly, because a smart list’s members change whenever a record’s values change, with nobody editing the list.

​
Connectors

  • Connector Event Received: Fires when a connected tool posts an event to its Custral event URL (create one under Settings → Connectors → Configure → Inbound events). Optionally pick one connector, and an event type: the body’s type, exactly, or a prefix ending in * (for example issue.*).

​
Communication

  • Email Received: Starts a workflow when an inbound email arrives on a connected Channel. Optionally filter by sender or channel.
  • Email Replied: Fires when a reply is received on a connected channel.
  • Conversation Outcome: Fires when a conversation reaches a specific outcome (disposition). Optionally filter by direction (Inbound / Outbound) and the agent who handled it.
  • Call Disposition: Fires when a phone call completes with one of the selected dispositions. Optionally filter by channel, direction, and agent.

​
Widget

  • Widget Chat Started: Fires when a website visitor starts a new chat via the widget.
  • Widget Visitor Identified: Fires when a widget visitor provides their contact information.
  • Widget Keyword Match: Fires when a widget visitor’s message matches configured keywords.
Two more triggers exist for their respective surfaces and are not used in standalone workflows: Enrollment (the start of a Sequence) and Query Target (the record/conversation selector for a Job).

​
Trigger Context

When a workflow is triggered, Custral passes along the data about the event. Subsequent Actions and edge conditions can reference that data with double curly braces. Wrap a value in {{ }} to insert it from the trigger, for example, the name of the record that changed or the email address of the sender. The action and condition editors show the values available from your chosen trigger. A Usage Changed trigger carries the reading that crossed, beside the record’s own fields: A Joins a List or Leaves a List trigger carries the record’s fields and the list: A Connector Event Received trigger carries the event. The posted body is also spread at the top level, so {{trigger.issue.title}} works:
You can only have one trigger per workflow. To handle multiple starting conditions, create separate workflows that point to the same logic or use Sequences.