Skip to content
ESEN

Triggers

The event that starts the workflow. Each workflow has one, and that event decides which data you can use in the rest of the steps.

How they work

  • One per workflow. To react to two different events, create two workflows. Use Duplicate so you do not start from scratch.
  • One run per event. Every time the event happens, an independent run is created. Ten quotes sent are ten runs.
  • Forward only. A workflow reacts to events that happen after it is published, not earlier ones.
  • Whoever causes it. The event counts whether it came from a team member, the client from their link, the API, an AI agent through MCP or another workflow. If the origin matters, use Who caused it in a condition.

In the editor, click Add a trigger and use Find a trigger or the categories: You run it, Scheduled, Quotes, Approvals, Payments, Invoices, Clients, Products, Tasks and promises and Automations. Before you type anything, the Suggested ones come first (the two You run it triggers and the scheduled one, which don’t depend on something happening in your account) and the rest follow, grouped by category.

Trigger search for a new workflow, filtered by Invoices: the 11 invoice events, from "A quote is invoiced" to "An invoice is marked uncollectible".

Data they carry

Most triggers for the same kind of object share data. To avoid repeating it in every table, these are the groups:

Group Data
Quote data Number, Client, Total, Currency, Status at the event, Current quote status, Who caused it
Invoice data Number, Client, Total, Balance due, Currency, Due date, Country, Status at the event, Current invoice status, Who caused it
Client data Company, Email, Country, Payment terms, Who caused it
Product data Name, List price, Active, Who caused it

In addition, every trigger carries your business data: name, contact email, phone, currency and today’s date in your time zone.

The exact name of each item for your texts (for example {{saldo_pendiente}}) is in Event data.

Only when: filter the trigger

In the trigger panel, Add a filter sets the conditions the event has to meet for the workflow to run, for example “Total is greater than $200,000.00 MXN” or “Number contains MAY”.

  • An event that does not meet it does not create a run: it does not appear in Runs. That is the difference from putting a condition as the first step, which leaves a run for every event.
  • The filter reads the data the event carries. What Cord reads live from the document, such as Current quote status, cannot be used here: use it in a condition or a wait.
  • You can require all the conditions or just one, as in a condition.
  • On the canvas, the trigger says “Only when” with the first condition.
  • Test uses the latest event that meets the filter, among the 20 most recent of that trigger.
  • The scheduled trigger has no filter: it brings no event to filter.

How often it enters

So the same thing is not repeated, the trigger panel has How often it enters:

Option What it does
Every time it happens Each event creates its run. This is the usual setting.
Once per document A quote or invoice that already entered does not create another run, even if the event happens again.
Once per client Counts by client: if a client already entered with one quote, another quote from the same client does not enter again. It only appears on triggers that carry a client.

With Can enter again after (days), the document or client enters again once that many days have passed since the last time; left empty, it never enters again. For example, “Once per client” with 30 days sends a collections reminder at most once a month to each client.

  • Entering is what counts, not the result: a run that fails also counts.
  • If the event does not carry that client, the run is created like any other instead of being lost.
  • It works with the filter: an event that does not pass the filter does not count as an entry.

You run it

Two triggers are started by a person, not by an event: You run it from a quote and You run it from an invoice. Use them for what has no fixed moment, like asking for a deposit, sending a collections sequence or telling the team about a special sale.

Trigger When it happens Data
You run it from a quote Someone runs it on one or more quotes. The same as any quote
You run it from an invoice Someone runs it on one or more invoices. The same as any invoice
  • From the document: on a quote or invoice detail, the Workflows section shows the active workflows for that type; click one to run it on that document.
  • In bulk: in the workflow editor, Run now opens the list of recent documents; choose up to 50 and each one starts its own run.
  • Which version: always the published one. If the workflow is a draft or paused, it is not offered.
  • Who can run it: whoever has the Quotes permission for a quote and Collections for an invoice. Actions run with the permissions of whoever published the workflow, as always.
  • The Only when… filter and How often it enters apply the same way: a document that does not meet them does not run, and Cord says so.
  • Who caused it is A team member; from your own system, with POST /v1/workflows/{id}/invoke in the API or the correr_workflow MCP tool, it is The API or An AI agent (MCP).

Scheduled

A workflow does not always react to something: it can also run on a fixed schedule. It is the only trigger you configure yourself.

Field Detail
How often Every day, every week or every month.
Day Of the week (Monday to Sunday) or of the month (1 to 28).
Time On the hour, in your account’s time zone (Settings › General). It runs in Cord’s first check after that time; Cord checks every 5 minutes.

It carries the tick’s own data: Date, Day of the week, Day of the month and Hour, usable in your text as {{fecha}}.

The day of the month caps at 28 on purpose: a “31” would silently skip February, and a monthly cut that never goes out is worse than one that goes out three days early.

A scheduled trigger carries no quote or invoice, so actions that act on a document — expire, void, email the client — cannot be used there, and the editor says so when you publish. What does fit: lookups plus an alert to the team, to Slack or to Teams.

When you pause a scheduled workflow its next tick is cleared; resuming recalculates it from that moment, so it does not fire the ticks it missed while paused.

Quotes

Trigger When it happens Data
A quote is created A new quote is saved, from the app, the API or an agent. Quote data
A quote is sent The quote is sent to the client and its link becomes active. Quote data
The client opens the quote The client opens the public link. It does not count when someone on your team opens the link to review it. Quote data
A quote is approved The quote becomes approved. Quote data
A quote is rejected The quote becomes rejected. Quote data
A quote is edited and resent A quote that was sent, viewed or expired is sent to the client again, usually after editing it. Quote data plus Previous total
A quote expires The validity date passes without the quote closing. Cord checks validity once a day. Quote data
A quote is about to expire Every day, while the expiration date is 1 to 30 days away and the quote is still sent or viewed. It carries Days until it expires and Expiration date: a condition picks the exact day you want to act on. Quote data plus the two date fields
A draft is deleted A draft quote is deleted. Quote data, without current status (the quote no longer exists)
A message is posted on a quote Someone writes in the quote chat. Quote data, Who wrote it (The client or The team) and Message

Approvals

Trigger When it happens Data
A quote requests internal approval A quote is created that, under your approval rules, needs sign-off from someone on your team before it is sent. Quote data and Reason
An internal approval is decided The approver decides. Quote data and Decision (Approved or Rejected)

Payments

Trigger When it happens Data
A quote is paid in full The quote is fully paid. Quote data
A partial payment arrives A payment that does not cover the total: a deposit, a balance, an installment or a payment of a milestone plan. Quote data, Amount paid, Balance due, Payment type (Deposit, Balance, Installment or Milestone payment) and Plan payment name
A payment plan milestone is completed You mark as completed a payment of a milestone plan that is due on completion; from then on your client can pay it. Quote data, Plan payment name, Payment amount and Due date
A recurring charge fails A recurring charge on a quote could not be collected. Quote data
A dispute is opened The client’s bank opens a dispute on an online payment. Quote number, Client, Disputed amount, Currency, Reason and Response deadline
A dispute is closed The dispute is resolved. Same as the dispute plus Outcome (Won, Lost or Closed without dispute)
A refund succeeds A refund reaches the client. Quote number, Client, Refunded amount, Currency and Reason
A refund fails The refund could not be completed. Same as the refund plus Failure reason
A payout is paid to your bank Cord Payments deposits your collections in your bank account. Payout amount, Currency and Arrival date
A payout fails Your bank rejects the payout. Same as the payout plus Failure reason
Your payments account changes What your Cord Payments account can do changes: accept payments, receive payouts, or whether it is missing information. Can accept online payments, Can receive payouts, Pending verification items and Restriction reason

Dispute, refund, payout and payments account events come from Cord Payments, so they only happen if you collect online with Cord. Each one is recorded only once even if the payment processor notifies several times. The quote number and the client come through when the movement belongs to a quote payment; a refund of an invoice payment brings them empty.

Invoices

Trigger When it happens Data
A quote is invoiced The quote is marked invoiced with a document that is not a CFDI, for example a standard invoice outside Mexico or a proforma. Quote data
A quote CFDI is stamped The quote is marked invoiced with a CFDI stamped with the SAT. Mexico only. Quote data
An invoice is issued A Cord Invoicing invoice is issued and receives its number. Invoice data
An invoice is sent The invoice is sent to the client. Invoice data
An invoice is paid The invoice becomes paid. Invoice data
An invoice payment fails A payment attempt on the invoice did not go through. Invoice data
An invoice becomes overdue The due date passes with a balance due. Cord checks this once a day. Invoice data
An invoice is about to be due Every day, while the due date is 1 to 30 days away and the invoice is still open with a balance. It carries Days until due and Due date. Invoice data plus the two date fields
An invoice has been past due for days Every day, from the day after the due date and up to 90 days later, while the invoice is still open with a balance. It carries Days past due. Invoice data plus the two date fields
An invoice is voided The invoice is voided. Invoice data
An invoice is marked uncollectible Someone marks the invoice as uncollectible. Invoice data

Clients

Trigger When it happens Data
A client is created A new client is added. Client data
A client is updated A client’s data changes, including changes coming from HubSpot. Client data plus the previous value of Company, Email and Payment terms
A client is deleted A client is deleted. Company and Who caused it

Products

Trigger When it happens Data
A product is created A product is added to the catalog. Product data
A product is updated A product’s data changes. Product data plus the previous value of List price and Active
A product is deleted A product is removed from the catalog. Name and Who caused it

Tasks and promises

Trigger When it happens Data
A task is created A task is added by hand, by another workflow, the API, or MCP. Tasks Cord creates on its own (chargeback, SPEI refund) don’t trigger it. Title and Who caused it
A task is completed A task is marked complete. Title and Who caused it
A payment promise is recorded You record that a client promised to pay. Promised amount, Promised date and Who caused it
A payment promise is kept The promise is marked kept. Promised amount and Who caused it
A payment promise is broken The promise is marked broken. Promised amount and Who caused it

Automations

They tell you how your own workflows end: use them to hear on Slack, Teams or email when an automation needs a person, without checking the Runs tab.

Trigger When it happens Data
A workflow run fails or needs attention A run of another workflow ends Failed or stops at Needs attention. Workflow, Document, Status, Reason and Link to its runs
A workflow run completes A run of another workflow ends without errors. Workflow, Document and Link to its runs
  • A workflow is not triggered by its own runs: the one that reports failures does not report itself when it fails.
  • To listen to just one, add the condition “Workflow is equal to” with its name.
  • Document is the number or name of what triggered the run, if it has one; for a scheduled workflow it is empty.

Time-based triggers

Three triggers are not caused by a person but by the calendar: A quote is about to expire, An invoice is about to be due and An invoice has been past due for days. Cord checks them once a day and emits them once per document per day, with the distance in days as data (Days until it expires, Days until due or Days past due).

  • You pick the exact day with a condition, for example “Days until due equals 3”. Without a condition, the workflow would run every day of the period.
  • They are only generated if an active workflow listens to them. If none of your active workflows uses that trigger, Cord does not emit it.
  • They are not sent to webhooks, Zapier, Make or n8n: a subscriber would get the same notice every day. They are exclusive to Cord Workflows, like the scheduled trigger.

The same events outside Workflows

42 of the 49 events can also be received outside Cord: in your webhooks and in the Zapier, Make and n8n triggers. The only ones that exist just inside Workflows are the three time-based triggers, the scheduled one, the two about workflow runs and the two you run yourself.

Trigger In Workflows In webhooks, Zapier, Make and n8n
The 42 quote, approval, payment, invoice, client, product, task and promise events Yes Yes, with their technical name (for example quote.approved)
A quote is about to expire Yes No
An invoice is about to be due Yes No
An invoice has been past due for days Yes No
On a fixed schedule Yes No
A workflow run fails or needs attention Yes No
A workflow run completes Yes No
You run it from a quote Yes No
You run it from an invoice Yes No

Who caused it

Quote, approval, quote payment, invoice, client, product, task and promise triggers carry Who caused it, with these values:

Value Meaning
The client Your client did it from their link: open, approve, reject, pay or write.
A team member A person in your organization, from the app.
The API An integration using your API key, for example Zapier or Make.
An AI agent (MCP) An AI assistant connected through MCP.
Another workflow One of your other workflows.
Cord automatically A Cord process, such as the daily due-date check, or a change that came from HubSpot.

A typical use: on A task is created, add the condition “Who caused it is not Another workflow” so you do not react to tasks created by your own workflows.