Trigger nodes

Every workflow starts with exactly one trigger — the event that kicks it off. When the event happens, the trigger fires the workflow and hands the rest of the steps a bundle of data about what just happened. You reach that data downstream with {{trigger.<field>}} templates (see Using variables).

Conversation context

Some triggers fire on a conversation — a new message, a resolution, a star. These carry a conversationId, so any conversation-scoped action (Send Message, Add Label, Assign…) works straight away.

Other triggers aren't tied to a conversation — an Incoming Webhook, a contact trigger such as Contact Stage Changed, or a Workflow Error. Under those, conversation actions have nothing to act on unless an earlier step supplies one (for example Send WhatsApp Template to a phone number creates a conversation, and Find Contact resolves a contact). Each trigger below notes whether it carries a conversation.

Conversation triggers

New Conversation

Fires when a brand-new conversation is created — the first inbound message on any channel. The most common starting point: welcome the customer, route them, or triage with AI.

• Carries a conversation: Yes
• Key variables: the shared conversation fields above, plus {{trigger.contactCreated}} — true when the contact was created for this conversation, false when a returning customer's conversation joined the contact they already have
• Returning customers: a new email conversation joins the contact who already has that address, and (rolling out to workspaces gradually) so does a new WhatsApp, Instagram, or Messenger conversation from someone you already know. Steps that change the contact — Change Contact Stage, Update Contact — then change that existing contact. To act only on first-time contacts, add a Decision before them: Variable trigger.contactCreated equals true.

Conversation Opened

Fires when a conversation's status changes to Open (for example, a resolved thread that gets a new reply).

• Carries a conversation: Yes
• Loop prevention: the Open Conversation action is hidden under this trigger — reopening on "opened" is a loop.

Conversation Resolved

Fires when a conversation is marked Resolved. Great for post-resolution follow-ups, satisfaction surveys, or advancing a contact's pipeline stage.

• Carries a conversation: Yes
• Loop prevention: the Resolve Conversation action is hidden under this trigger.

Conversation Starred

Fires when a conversation is starred.

• Carries a conversation: Yes
• Loop prevention: the Star Conversation action is hidden under this trigger.

WhatsApp Flow Submitted

Fires when a customer completes and submits a WhatsApp Flow — a native in-chat form (booking, lead capture, survey). The answers arrive as variables you can branch on and reuse. See WhatsApp Flows.

• Carries a conversation: Yes
• Key variables:
  • {{trigger.flowValues.<field>}} — the submitted answers, keyed by field name (e.g. {{trigger.flowValues.km_range}}). Match on them with a Decision node's Variable condition.
  • {{trigger.flowToken}} — the token stamped on the outbound send and echoed back
  • {{trigger.flowSource}} — where the flow was sent from (oneoff, campaign, workflow, sample, api)
  • {{trigger.campaignId}} — set when a campaign sent the flow
  • {{trigger.templateName}} — the template whose button opened the flow, when known

Because every flow asks different questions, flowValues can't be listed ahead of time. Open the trigger and Select a flow — Cloodot reads the answer fields straight out of that flow's design, and they become {{trigger.flowValues.…}} suggestions in every later step. Picking a flow only names the fields; the trigger still fires for every flow, so branch on an answer with a Decision node if a workflow should serve one flow only.

Routing triggers

AI Agent Assigned

Fires when an AI persona is assigned to a conversation. Use it to set up context the moment AI takes over.

• Carries a conversation: Yes
• Key variable: {{trigger.personaVersionId}} — the assigned AI persona version

Human Agent Assigned

Fires when a team member is assigned to a conversation — for notifications, logging, or SLA timers.

• Carries a conversation: Yes
• Key variable: {{trigger.userId}} — the assigned user

AI trigger

AI Agent Skill

Fires when the AI agent calls this workflow as a skill during a conversation — not on an event, but because the agent decided this was the thing to do, with the arguments it filled in. The trigger node's fields are the tool the agent is offered: its name, the description it reads to choose, and the arguments it fills. Full guide: AI agent skills.

• Carries a conversation: Yes — the agent only ever calls a skill from inside a conversation it's handling, so conversation actions work with nothing extra.
• Key variables:
  • {{trigger.input.<name>}} — the arguments the agent passed, one per row you declared (e.g. {{trigger.input.orderId}}). They appear in the Variables picker by name the moment you add them.
  • {{trigger.skillName}} — the skill's own name
• Configured on the trigger: Skill name (3–48 characters, lowercase letters, numbers and underscores, starting with a letter — offered to the agent as flow_<name>), When should the agent use this? (≤1,000 characters), Arguments (up to 10, each string, number or boolean), and Wait for a reply to the agent with a Give up after budget of 3–60 seconds.
• Answering: a Reply to Agent step hands the agent a result without ending the run — the steps after it keep going. That step only works under this trigger.

Label triggers

Label Added

Fires when a label is added to a conversation. A label makes a clean signal — tag something manually or with AI, and let this trigger do the rest.

• Carries a conversation: Yes
• Key variable: {{trigger.labelIds}} — the label IDs that were added
• Loop prevention: the Add Label action is hidden under this trigger.

Label Removed

Fires when a label is removed from a conversation.

• Carries a conversation: Yes
• Key variable: {{trigger.labelIds}} — the label IDs that were removed
• Loop prevention: the Remove Label action is hidden under this trigger.

CRM triggers

These fire on a contact record, not a conversation. They carry {{trigger.contactId}}, {{trigger.contactName}}, {{trigger.contactEmail}}, {{trigger.contactPhone}}, {{trigger.stageId}}, {{trigger.stageName}} and {{trigger.source}} — where the change came from: dashboard (someone in Cloodot), api (public API, MCP, Copilot), inbound (the customer, on a channel), import, integration, ai or workflow. When the source is workflow, {{trigger.sourceWorkflowId}} names the workflow that made the change.

• Carries a conversation: No. Conversation actions need a conversation supplied by an earlier step (e.g. Send WhatsApp Template to {{trigger.contactPhone}}). Update Contact and Change Contact Stage work on the contact that started the run without any setup (rolling out gradually).

Contact Created

Fires when a contact is added. Choose which sources start it (see Which changes start a contact trigger).

A contact created already in a stage (by a workflow, say) fires Contact Created only — its stage is in {{trigger.stageName}} — not Contact Stage Changed as well.

• Loop prevention: the Create Contact action is hidden under this trigger.

Contact Updated

Fires when a contact's details change. It only fires when something actually changed — saving an unchanged form is silent.

• Key variables: {{trigger.updatedFields}} — the built-in fields that changed (name, email, phone, stageId, …) · {{trigger.updatedCustomFieldIds}} — the custom fields whose value changed · {{trigger.mergedContactIds}} — set when the update was a merge, which fires this trigger even when no field changed.
• Loop prevention: the Update Contact action is hidden under this trigger.

Contact Stage Changed

Fires when a contact's lifecycle stage changes — for example, moving from New to Qualified on the Contacts page's stage board. Use it to run a playbook every time a contact reaches a stage.

It also fires when a merge gives the kept contact another contact's stage.

• Key variables:
  • {{trigger.contactId}} · {{trigger.contactName}} · {{trigger.source}}
  • {{trigger.fromStageId}} · {{trigger.fromStageName}} — the previous stage (absent if the contact had none before)
  • {{trigger.toStageId}} · {{trigger.toStageName}} — the new stage
  • {{trigger.mergedContactIds}} — set when a merge moved the stage: the contacts merged into this one. Check it to skip a stage that one of them may already have reached.
• Loop prevention: the Change Contact Stage action is hidden under this trigger.

Contact Owner Changed

Fires when a contact gets a new owner or loses one — claimed, assigned (by a teammate, the API or a workflow), taken by the first teammate to reply, dealt out by round robin, or taken from a merge. See Contact owners. Rolling out gradually.

• Key variables:
  • the contact variables above, and {{trigger.source}}
  • {{trigger.ownerId}} · {{trigger.ownerName}} · {{trigger.ownerEmail}} — the new owner (absent when the owner was removed); to tell them, add Send Notification, choose Teammates and tick The contact's new owner
  • {{trigger.previousOwnerId}} · {{trigger.previousOwnerName}} — the previous owner (absent if there was none)
  • {{trigger.reason}} — claimed, assigned, released, first_reply, round_robin, or merged when a merge changed the owner. Check it to tell a merge from a claim or an assignment.
• Sources: People (claims, assigns, first reply), API, Incoming messages (round robin for a new conversation's contact) and Other automations.
• An owner change never fires Contact Updated. Owners released automatically after a quiet spell don't start any workflow.
• Loop prevention: the Assign Contact Owner action is hidden under this trigger.

Contact Deleted

Fires when a contact is deleted — by people or the API — or merged into another contact. The record is already gone when the workflow runs, so the variables carry its last known details. {{trigger.mergedIntoContactId}} is set when it was a merge.

Task Completed

Fires when a task on a contact is marked done — from the Tasks page, the contact's Open tasks block, the API or MCP. Use it to chain the next step of a cadence, for example "when Send the quote is done, create Call back in 2 days". Rolling out gradually.

• Key variables:
  • the contact variables above, and {{trigger.source}}
  • {{trigger.taskId}} · {{trigger.taskTitle}} · {{trigger.taskType}} (TODO, CALL, FOLLOW_UP or MEETING) · {{trigger.taskNotes}} · {{trigger.taskDueAt}}
  • {{trigger.wasOverdue}} — true when it was completed after its due time
  • {{trigger.assigneeId}} · {{trigger.assigneeName}} — who it was assigned to (absent when unassigned)
  • {{trigger.completedById}} · {{trigger.completedByName}} — who completed it (completedById is a member id)
  • {{trigger.taskConversationId}} — the chat the task was added from, when there was one. It doesn't bind the run to that chat.
• Sources: People and API.
• Fires once per completion: two people ticking the same task at the same moment start one run. Reopening a task and completing it again fires again. Editing a task — its title, due time, assignee — never fires it, and neither does adding or deleting one.

Call Logged

Fires when someone logs a call with a contact — from the contact drawer, a watchlist row, the API or MCP. Rolling out gradually.

• Key variables:
  • the contact variables above, and {{trigger.source}}
  • {{trigger.callId}} · {{trigger.direction}} (outbound or inbound)
  • {{trigger.outcome}} — connected, no_answer, voicemail, busy, wrong_number or callback_requested
  • {{trigger.durationSeconds}} (absent when not entered) · {{trigger.callNote}} · {{trigger.calledAt}}
  • {{trigger.loggedById}} · {{trigger.loggedByName}} — who logged it
  • {{trigger.followUpTaskId}} — the follow-up task added with the call, when there was one
• Sources: People and API.
• Fires once when the call is logged. Editing or deleting a call never fires it. Logging a call doesn't change the contact, so it never fires Contact Updated.

Deal Created, Deal Stage Changed, Deal Won, Deal Lost

Four triggers for deals. Rolling out gradually; in a workspace without deals they aren't offered and don't run.

• Deal Created — a deal is added, from the board, a contact, the API or a Create Deal step. A deal created straight into Won or Lost also fires Deal Won or Deal Lost.
• Deal Stage Changed — a deal moves to another stage: dragged on the board, moved in its drawer, closed, reopened, or moved to another pipeline.
• Deal Won / Deal Lost — a deal enters its pipeline's Won or Lost stage. Closing a deal fires Deal Stage Changed too, so a workflow on Stage Changed sees every move, closes included.
• Key variables:
  • the contact variables above ({{trigger.stageName}} is the contact's lifecycle stage), and {{trigger.source}}
  • {{trigger.dealId}} · {{trigger.dealTitle}} · {{trigger.dealAmount}} (a number, absent when the deal has no amount) · {{trigger.dealCurrency}}
  • {{trigger.dealStatus}} (open, won or lost) · {{trigger.dealPipelineId}} · {{trigger.dealPipelineName}}
  • {{trigger.dealStageId}} · {{trigger.dealStageName}} · {{trigger.dealStageType}} · {{trigger.dealProbability}}
  • {{trigger.dealExpectedCloseDate}} (YYYY-MM-DD) · {{trigger.dealOwnerId}} · {{trigger.dealOwnerName}} · {{trigger.dealOwnerEmail}} · {{trigger.dealCreatedAt}}
  • Deal Stage Changed adds {{trigger.previousDealStageId}} · {{trigger.previousDealStageName}} · {{trigger.previousDealStageType}}, and {{trigger.previousDealPipelineName}} when the deal changed pipeline
  • Deal Won and Deal Lost add {{trigger.dealClosedAt}}; Deal Lost adds {{trigger.lostReason}} · {{trigger.lostReasonNote}}
• Sources: People, API and Other automations (off until you tick it, like every contact trigger).
• Editing a deal's title, amount, close date or owner never fires them, and neither does deleting or restoring one. When an admin deletes a stage and its deals move to another stage, no workflow runs. Deal triggers never fire Contact Updated.
• To act on big deals only, add a Decision: Variable trigger.dealAmount greater than 5000.

Which changes start a contact trigger

Open the trigger to choose, under Runs for changes made by:

• People — your team in Cloodot: the Contacts page, the inbox and bulk actions.
• API — the public API, MCP clients and Copilot.
• Incoming messages — a customer messaging you: a new contact, details they share, a changed number, an opt-out.
• Imports — CSV imports, only when you tick Run automations for these contacts when importing.
• Integrations — Shopify and WhatsApp Business App syncs. A sync of more than 25 contacts at once never starts runs, and neither does a store's first Shopify sync.
• AI — your AI agent filling in details from a conversation.
• Other automations — changes made by other workflows. Off unless you tick it; a workflow never starts itself, and a chain of workflows starting each other stops after three.

A new contact trigger, including one from a template, starts with every source ticked except Other automations. A contact trigger with no sources chosen — one set up before you could choose, or created through the API without a list — runs for People and API only, until you tick more.

Contacts created only to send a message — a one-off template, a campaign, a workflow sending to a new number — never start Contact Created. Dragging cards on the Contacts page's stage board (the Pipeline or Stages layout) or a watchlist board, and changing the stage of selected contacts on the Contacts page, start Contact Stage Changed for each contact but not Contact Updated, even when you move a single card. Changing one contact's stage in its details, in the Contacts table's stage column or in the inbox starts both.

Rolling out gradually: until it reaches your workspace, contact triggers start from people and the API only.

Webhook trigger

Incoming Webhook

Fires when an external system POSTs JSON to the workflow's unique URL. This is how you wire Cloodot to any tool that can send a webhook — a store, a form, a CRM, a no-code automation.

• Carries a conversation: No — the payload is free-form JSON.
• Key variables: anything in the posted body, addressed by path — {{trigger.payload.order.id}}, {{trigger.payload.items.0.sku}}, and so on.

Setup, in the trigger's panel:

• The panel shows the endpoint URL and a signing secret. By default every request must be signed (HMAC-SHA256 — the panel shows exactly how).
• If your sender can't sign requests (a simple script or no-code tool), switch off Require signed requests. Anyone who knows the URL can then trigger the workflow, so treat the URL like a password.
• Use Listen for a request in the Sample event section to capture one real request — it works before the workflow is published. The captured fields then show up as variable suggestions on every later step, and dry runs are prefilled with them. The first real event is captured automatically if you never listen.

When the sender signs in its own scheme

Services like Razorpay, Stripe, AfterShip, Cal.com, and ShipRocket sign their webhooks in their own dialect — you can't teach them Cloodot's. The How does the sender sign? picker in the trigger panel switches verification to the provider's scheme; requests are then checked exactly the way that provider signs them, and the Cloodot signing headers stop mattering.

Picking a scheme changes three things in the panel:

• The signing secret becomes the provider's — paste the secret the provider shows you when you create the webhook in their dashboard. If the workflow was installed by a skill set, the secret lives in that skill set's install settings instead, and the panel says so: update it there and every workflow the skill set installed picks up the new value.
• The test request re-templates to the picked scheme — the right header, digest, and signed material for that provider, ready to paste into a terminal. Schemes that sign a timestamp get one; schemes with a delivery id get a fresh one per run, so a repeated test is never mistaken for a duplicate delivery.
• Duplicate deliveries are suppressed. Providers redeliver on any hiccup; when the scheme carries a delivery id, a redelivered event runs once, not twice — for seven days per id.

Verification always fails closed: a request that doesn't verify — wrong signature, unresolvable secret — is rejected without a reason in the response, and nothing runs.

Shopify trigger

Cart Abandoned

Fires when a shopper who started checkout — and gave an email or phone number — leaves it untouched for the wait you set, without placing an order. Built for recovery nudges: each workflow runs at most once per checkout, and never after the shopper buys.

• Carries a conversation: No — most shoppers who abandon a checkout have never messaged you. {{trigger.conversationId}} is filled in when the shopper is already a contact with a conversation; otherwise reach them with Send WhatsApp Template to {{trigger.customerPhone}}.
• Key variables: {{trigger.recoveryUrl}} (the link back into their checkout, items restored) · {{trigger.firstName}} · {{trigger.itemsSummary}} · {{trigger.totalPrice}} · {{trigger.currency}} · {{trigger.customerPhone}} · {{trigger.customerEmail}} · {{trigger.acceptsMarketing}} · {{trigger.acceptsSmsMarketing}} · {{trigger.lineItems}} · {{trigger.lastActivityAt}}

Setup, in the trigger's panel: set Fire after — how long the checkout must sit untouched, from 15 minutes to 7 days (30 minutes if you don't change it).

How the wait behaves:

• Every checkout change restarts it. A shopper who edits their checkout at 10:00, 10:15, 10:16 and 10:18 gets one nudge, 30 minutes after 10:18 — not four.
• A purchase cancels it — an order from that checkout, or from the same shopper (matched on email or phone) checking out on another device.
• Only their latest checkout counts. If the same shopper leaves a newer checkout — on another device, or because Shopify reissued the one they were in — the older one is dropped, so they hear about their current cart once.
• One workflow per reminder. For a sequence — say 1 hour, 24 hours and 3 days — build one workflow per touch, each with its own wait. A purchase cancels every touch still waiting. Don't chain Delay steps after this trigger: a run already waiting on a Delay isn't cancelled by the purchase.

System trigger

Workflow Error

Runs when another workflow fails for good (after all its retries). Build an error handler once — alert a channel, log to an external service — and point other workflows at it under their execution settings.

• Carries a conversation: Not guaranteed — error handlers must work for non-conversation workflows too. {{trigger.conversationId}} is present only when the failed run had one.
• Key variables: {{trigger.failedWorkflowName}} · {{trigger.failedWorkflowId}} · {{trigger.error}} · {{trigger.failedRunNumber}} · {{trigger.failedExecutionId}} · {{trigger.failedAt}} · {{trigger.retryCount}}

Related