Browse documentation

Automations

When/If/Then rules that react to deal, contact, and company events: the triggers, the step types, who can create and manage a rule, and how run history works.

Updated 2026-10-14

An automation is a When/If/Then rule: When an event happens, If its conditions match, Then run a list of steps in order. Automations live at /automations and react to deal, contact, and company events — there is no workspace-level toggle, every workspace has the feature.

Triggers

  • Deal created
  • Deal stage changed
  • Deal status changed (open/won/lost)
  • Deal field changed — pick a specific field (built-in or custom) to watch
  • Before stage change — a synchronous gate that runs while the move is happening, not after; it uses a different pair of step types (see the callout below) — see stage preflight checks for the full behavior
  • Contact created
  • Contact assigned — fires when a contact gets an owner, including a first assignment
  • Contact field changed — pick a specific field (built-in or custom) to watch, same shape as deal field changed
  • Company created
  • Company assigned — fires when a company gets an owner, including a first assignment

Building one

A simple automation opens as one sentence: “When a deal is created, in Qualifying, then tell Sally: ‘Request the invoice’.” Click any part of the sentence to change it. An automation that uses a wait, an If / otherwise, a Before stage change trigger, or more than one filter opens in the full editor instead, and the Simple and Full editor toggle switches between the two when both fit. Both views edit the same automation, and it saves as you go. The add-step menu groups steps by what they do: Let people know, Do the work, and More options.

The automations list

Each row at /automations shows the automation’s name with a sentence under it, such as “When a deal moves to Request Invoice → tell Me.” The sentence describes the live version when the automation is on, and the draft otherwise. A rule too long for one sentence shows its trigger and “+ N more rules.” A status badge reads On, Off or Draft, with Unpublished changes when the draft differs from the live version. A red Failing badge appears when the latest run failed or any step failed in the last 7 days. The row also shows the owner and the date of the last run.

Starting from a recipe

New automation offers seven recipes, and the empty list shows them too: Tell me when a deal reaches a stage, Ask the owner to request the invoice when a deal is won, Stage follow-up email to brand contacts, Won-deal post, Lost-deal task for the owner, Stale-stage reminder, and High-value alert (a deal created over 10,000 in your workspace currency, offered only to members who can see financials, since it sets an amount). A recipe that depends on a stage asks for it once before it builds. Anything a recipe cannot know, such as an email template or a Slack channel, starts empty and has to be chosen before the automation can be turned on.

On the pipeline board, the menu in a stage’s header has Automate this stage. It starts a Tell me when a deal reaches a stage automation for that stage. It is available on the desktop board, not on the phone layout.

Turning one on

A new automation is a Draft and does nothing until you turn it on. A panel above the builder lists what must be fixed first (marked Must fix) and what is worth a look (marked Check). Common fixes are one click away: connect or reconnect Gmail, write an email template without leaving the page, or connect Slack or Discord. An automation with no steps cannot be turned on. The button reads Turn on for a draft and Update live version when you have edited an automation that is already on. The More actions menu has Turn off, Duplicate and Delete, and Turn on the live version when an automation is off and you have edited it since.

Each automation shows who it runs as: its creator. Emails from “my inbox” are sent from that person’s Gmail, so that person is the one who connects Gmail. Anyone else opening it sees a note that only the creator or a workspace admin can change it, and the builder is read-only.

Steps

A rule runs its steps in order once its conditions match. Available step types:

StepWhat it does
Notify teammatesIn-app notification to the deal/contact/company owner or specific members.
Post in Slack or DiscordSends a message to a connected Slack or Discord channel or DM, with @-mentions for the deal owner, deal team, contacts, linked talent, or a specific member/role (a contact or company run can only @-mention a specific member/role — see below).
Email from my inboxSends one templated email when the rule runs. On a deal trigger it can go to the deal contacts or the linked talent (to tell the deal owner, add a Notify teammates step instead); on a contact trigger it goes to that contact’s own email address. Not available on a company trigger (companies have no email address), see the callout below.
Create a dealOpens a deal in a chosen stage for the contact or company that triggered the run — contact/company triggers only, not offered on a deal trigger. See Create a deal below.
Create a taskCreates a next action on the deal, due a set number of days out.
Update the dealChanges the deal’s stage, status, owner, or a field.
Add a noteLogs a note on the deal timeline.
WaitPauses the rule for up to 30 days before continuing.
If / otherwiseSplits into two step lists based on a condition.

The Before stage change trigger offers a different pair of steps — Automatic check and Manual confirmation — used to gate a move rather than react to it. Every other DEAL trigger uses the full step list above; contact and company triggers use a narrower set — see Contact and company automations below.

Contact and company automations

Contact and company triggers react the same way deal triggers react to deals — When/If/Then, same builder, same test flow — but with a smaller step list: Notify teammates, Post in Slack or Discord, Create a deal, Wait, and If / otherwise. A contact trigger additionally offers Email from my inbox (see below). The deal-only steps (Create a task, Update the deal, Add a note) aren’t offered for either, since they need a deal to write to.

  • Notify teammates: the contact/company owner or specific members.
  • Post in Slack or Discord: @-mentions support a specific member/role, but not the deal-only mention kinds (deal owner, deal team, deal contacts, linked talent) — a contact or company run has no deal to derive them from.
  • Every workspace member can already see every contact and company, so a contact- or company-triggered notification or ping has no visibility gate to check — unlike a deal-triggered one, which only reaches people who can see that deal.

Create a deal

Create a deal opens a deal in a stage you choose, for a contact- or company-triggered run — for example, “new contact created → open a deal in the Qualifying stage, owned by that contact’s owner.” The title is a template (defaults to the contact’s or company’s own name) and the owner can be the triggering record’s own owner, a specific member, or unassigned. By default the step skips (and says why) if that contact or company already has an open deal, so re-running the trigger doesn’t pile up duplicates.

A deal opened this way can itself fire its own deal-triggered automations (a “deal created” rule still runs). Chains are bounded — an automation cannot cascade into itself indefinitely.

Email from my inbox on a contact trigger

A contact-triggered rule can send a templated email to the contact that triggered it — for example, “new contact created → send the Welcome template.” It’s a single templated send at the moment the trigger fires, using the same templates and the same connected-Gmail sending path as a deal automation’s send email step. If the contact has no email address on file, the step either skips (and says why) or fails the run, whichever you configured.

This is one email per trigger event, not a sequence: there’s no scheduling, no multi-step drip campaign, and no send-history or suppression list to track repeat sends. Company triggers don’t offer send email — companies have no email address.

Who can create and manage automations

Any workspace member can create an automation and see every automation in the workspace — membership alone is the gate for creating and viewing. Editing or deleting a specific automation is restricted to its creator or a workspace owner/admin.

Run history

Every automation keeps a history of its runs, one per matching event. Any member can see the run list — status, which deal, contact, or company it ran against, and when. A run’s detail names its trigger in plain words and lists the conditions it checked by name; a stage, member or field that no longer exists reads as “a deleted stage,” “a former member” or “a removed field.” A failed step says what went wrong and offers a way forward: Fix in editor opens the automation at that step, and a run on a deal that was deleted or archived links to Trash if you can open it (otherwise it tells you to ask an admin). Trash holds deals only: a contact or company that was archived is unarchived from its own page. A condition on a money field shows as hidden if you can’t see financials. The same goes for the automation itself: if you can’t see financials, every amount in it (a deal value threshold, a value an Update the deal or Create a deal step would write) reads as “Amount hidden” in the editor, the list and test runs. You can still edit the rest of the automation and keep, move or remove a hidden amount, but you can’t set or change one. A run for a deal you can’t otherwise see (per your deal visibility) never appears at all; contact and company runs have no equivalent filter — every workspace member can see every contact and company, so those runs are visible to any member who can see the automation.

Step-by-step input and output — the rendered message text, the field values a step wrote — is only visible to the automation’s creator or a workspace owner/admin. Everyone else sees the run’s steps and status, with the payloads hidden.

Test runs

Before turning an automation on, use Preview to pick a real record and dry-run the automation against it. The button says Preview on a deal, contact, or company to match the rule’s trigger. You see whether the conditions matched and what each step would have sent or written, with no external messages sent, no email sent, and no changes saved. Once an automation is published, a second explicit step lets you run it for real against that same record, which goes through the same pipeline as a live trigger and shows up in run history.

Spotted something out of date? Email hello@neokivo.com.