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-07-24
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
Steps
A rule runs its steps in order once its conditions match. Available step types:
| Step | What it does |
|---|---|
| Send notification | In-app notification to the deal/contact/company owner or specific members. |
| Post to a channel | Sends a message to a connected Slack or Discord channel or DM, with @-mentions for the deal owner, deal team, contacts, linked client, or a specific member/role (a contact or company run can only @-mention a specific member/role — see below). |
| Send email | Sends one templated email when the rule runs. On a deal trigger it can go to the deal contacts, the linked client, or the deal owner; 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 deal | Opens 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 deal below. |
| Create task | Creates a next action on the deal, due a set number of days out. |
| Update deal | Changes the deal’s stage, status, owner, or a field. |
| Add note | Logs a note on the deal timeline. |
| Wait | Pauses the rule for up to 30 days before continuing. |
| If / else branch | Splits 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, post to a channel, create deal, wait, and if/else branch. A contact trigger additionally offers send email (see below). The deal-only steps (create task, update deal, add note) aren’t offered for either, since they need a deal to write to.
- Notify: the contact/company owner or specific members.
- Post to a channel: @-mentions support a specific member/role, but not the deal-only mention kinds (deal owner, deal team, deal contacts, linked client) — 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 deal
Create 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.
Send email 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 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 publishing, use Test to pick a real record and dry-run the automation against it — a deal, contact, or company, matching 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.