Module · A system, a clock or a person

Click trigger

Lesson 10 of 10 · 3 min

Nine triggers so far fire on their own — data changed, someone messaged, a clock came round. This one waits to be asked.

The Click trigger puts a button in the CRM. Someone looking at a contact presses it, and the workflow runs on that record.

A worked example

A button on a contact

The button hands the workflow the record it was pressed on.

What the button sends

Reference	Holds
`{{clicktrigger_1.entity_id}}`	The record the button was pressed on.
`{{clicktrigger_1.entity_type}}`	What kind of record — contact, deal, company.
`{{clicktrigger_1.trigger_source}}`	Where the press came from.
`{{clicktrigger_1.trigger_metadata}}`	Anything else the button chose to send.

{{clicktrigger_1.entity_id}}

Holds: The record the button was pressed on.

{{clicktrigger_1.entity_type}}

Holds: What kind of record — contact, deal, company.

{{clicktrigger_1.trigger_source}}

Holds: Where the press came from.

{{clicktrigger_1.trigger_metadata}}

Holds: Anything else the button chose to send.

expected_variables declares what the button promises to provide. It is a contract rather than an enforcement, and it is worth filling in honestly — it is the only place a reader can see what this workflow assumes it will be given.

Configuration

Mostly presentation — because most of this node is a button.

Field	What it holds
`trigger_uuid`	Unique identifier for this trigger (auto-generated)
`trigger_name`	Human-readable name for this trigger Defaults to `Click Trigger`.
`button_text`	Text to display on frontend buttons Defaults to `Execute Workflow`.
`button_style`	Button appearance style One of: `primary · secondary · success · warning · danger` Defaults to `primary`.
`button_icon`	Icon for frontend buttons (lucide icon name) Defaults to `play`.
`listen_to_buttons`	External button UUIDs this workflow should listen to
`expected_variables`	Variable names expected from button clicks
`description`	Description of what this trigger does Defaults to `Triggers workflow when button is clicked`.

trigger_uuid

What it holds: Unique identifier for this trigger (auto-generated)

trigger_name

What it holds: Human-readable name for this trigger Defaults to Click Trigger.

button_text

What it holds: Text to display on frontend buttons Defaults to Execute Workflow.

button_style

What it holds: Button appearance style One of: primary · secondary · success · warning · danger Defaults to primary.

button_icon

What it holds: Icon for frontend buttons (lucide icon name) Defaults to play.

listen_to_buttons

What it holds: External button UUIDs this workflow should listen to

expected_variables

What it holds: Variable names expected from button clicks

description

What it holds: Description of what this trigger does Defaults to Triggers workflow when button is clicked.

The UUID is generated, and it is the thing that must not change. trigger_uuid is the stable identifier a button posts against. Like the webhook URL, it appears when the workflow is saved. Once a button somewhere is wired to it, changing it breaks that button — so treat it as permanent from the moment it is used.

listen_to_buttons lets one workflow answer several buttons. Useful when the same action belongs on contacts, companies and deals: one workflow, three buttons, and entity_type tells it which it was.

Why this trigger matters more than it looks

It is the gentlest way to bring automation to a team that has not asked for it. Automatic triggers change what happens without anyone choosing; a button changes nothing until somebody presses it.

It is opt-in. Nobody's workflow is altered. The button sits there until it is useful.
It is where the work is. On the record, in the CRM, not in a separate tool people have to remember.
It teaches the value. “Press this and the summary writes itself” is a demonstration. Once a team presses it fifty times, the case for making it automatic makes itself.

A good pattern is to ship the button first and automate second: the same workflow, later re-triggered by a Database Change, once everyone agrees it should just happen.

That is all ten

The ten triggers answer six questions, and once you can name the question you can pick the trigger without a list:

The question	The trigger
A record changed.	`universal_database_trigger`
A contact's group membership changed.	`segment_trigger`
A date on a record is approaching.	`due_time_trigger`
Someone contacted us.	`user_message_trigger` · `whatsapp_context_input` · `voice_inbound_trigger`
Another system has news.	`webhook_trigger` · `google_calendar_trigger` · `google_sheets_trigger`
A person asked for it.	`click_trigger`

A record changed.

The trigger: universal_database_trigger

A contact's group membership changed.

The trigger: segment_trigger

A date on a record is approaching.

The trigger: due_time_trigger

Someone contacted us.

The trigger: user_message_trigger · whatsapp_context_input · voice_inbound_trigger

Another system has news.

The trigger: webhook_trigger · google_calendar_trigger · google_sheets_trigger

A person asked for it.

The trigger: click_trigger

The product has more trigger types than these ten, and they are all variations on the same six questions — a different calendar, a different chat provider, a different spreadsheet. Learn the question and the rest read themselves.

Try it

Add a Click trigger, give the button a name someone else would understand, and save the workflow.
Have it write a note containing {{clicktrigger_1.entity_id}}, then press it from a contact.
Set expected_variables to what the button really provides, and read it back in a week — that is the field's whole purpose.
Then ask which of your automatic workflows would have been easier to introduce as a button first.

That completes the Triggers path. You can now start a workflow from a record change, a group change, a date, a chat message, a WhatsApp thread, a phone call, an HTTP request, a calendar, a spreadsheet, or a button — which is every way a workflow can begin.