Automations
Automations across the whole business
Trigger → condition → action
Every automation follows the same shape. A trigger is a meaningful event — a deal changing stage, an order arriving, a work item's due date approaching. Optional conditions narrow that down to the cases you actually care about, filtering on fields like deal value, order total, customer segment, priority, pipeline or assignee. When both the trigger fires and the conditions pass, one or more actions run.
That structure is deliberately plain rather than a visual flowchart builder with branches and delays — it is easy to read back a year later and know exactly what a rule does and why it fired.
11 triggers
Triggers span the CRM, commerce and work-management sides of the platform:
- Deal created
- Deal stage changed
- Deal won
- Deal lost
- Contact created
- Order synced (from WooCommerce or the order intake endpoint)
- Customer segment changed (RFM segment movement, such as into At-risk)
- Work item created
- Work item status changed
- Work item due date approaching
- Form submitted
Plus scheduled triggers, which fire on a time-based schedule rather than in response to an event — covered separately below, because they carry an honest caveat about WordPress cron.
Conditions
Conditions are filter-style checks evaluated against the fields relevant to the trigger that fired — deal value, order total, customer segment, priority, pipeline, assignee, and other record attributes along those lines. They are what turns "an order arrived" into "an order over $10,000 arrived," and they can be combined so a single automation only fires for the exact situation you are targeting.
10 actions
- Create a project from a template
- Create a work item
- Create a CRM follow-up
- Set status
- Set priority
- Assign to a user (including round-robin)
- Send a notification
- Add a comment
- Link a record
- Fire a webhook
Never fires twice: idempotency by design
The action that matters most to get right is also the one where a duplicate run does real damage: creating a project when a deal is won. If the "deal won" event were delivered twice — a retried webhook, a resaved record, a race between two processes — a naive automation would spin up two projects, two sets of tasks and two timelines for the same customer.
Every automation run in Stillpoint is recorded against an idempotency key derived from the trigger and the record it fired on, so a repeat delivery of the same event is recognised and skipped rather than re-executed. That is what makes it safe to wire automations to consequential, record-creating actions rather than keeping them to low-stakes notifications only.
Seven ready-made automations, and how they read
Below are worked examples in the trigger → condition → action shape. Five map to the seven ready-made automations that ship with Stillpoint; all seven are available to enable and adjust from the automations settings screen.
Deal won → onboarding project from template
The moment a deal's status flips to won, a new project is created from your chosen onboarding template — with its predefined tasks and structure already in place — and linked back to the deal and the contact, so the handoff from sales to delivery happens without a manual step or a Slack message someone might miss.
Order over $10,000 → VIP handling task
A large order gets flagged for hands-on attention — a packing check, a personal thank-you, a proactive shipping update — instead of being processed identically to a routine order.
Customer becomes At-risk → win-back task
RFM segmentation on the commerce side already knows a customer has gone quiet. This turns that signal into a scheduled follow-up for a real person to reach out, rather than a segment label nobody acts on.
Refund → service recovery task
A refund is often the first sign something needs a human follow-up — a broken product, a service issue, a customer worth calling. This raises a task the moment it happens instead of the refund quietly disappearing into the order history.
Form submission → work item + round-robin assignment
An inbound form submission becomes a tracked work item and lands on a rep's queue immediately, distributed evenly across the active team so no single person absorbs every enquiry and nothing sits unowned.
Scheduled triggers need real cron
Scheduled triggers — "run this every day," "check for stale deals every Monday" — rely on WordPress's own cron system, and WordPress cron is not a real background scheduler by default. It runs its pending jobs when a visitor loads a page on your site, which works fine on a busy site and can quietly fall behind on a quiet one.
We recommend disabling WordPress's page-load-triggered pseudo-cron and pointing a real system cron job — or your host's cron feature, if you don't have shell access — at wp-cron.php on a fixed interval, typically every five minutes. That is a WordPress-level setup step, not a Stillpoint setting, and it's covered along with the rest of initial setup on the getting-started guide.
Where automations fit next to reporting and work
Automations are the connective tissue between the pillars: they read from the CRM and WooCommerce orders, and they write into work management. Every run they perform is itself an event you can find later in reporting through the records it created, and outbound webhooks let a rule hand off to a separate marketing automation tool when the next step is a campaign rather than a CRM action.
Frequently asked questions
No. Every automation run is recorded with an idempotency key, so a "deal won → create onboarding project" rule cannot fire twice for the same deal even if the underlying event is delivered more than once — for example if a webhook retries, or a status is re-saved without actually changing. That guarantee is what makes it safe to wire automations to consequential actions like project creation rather than only to low-stakes notifications.
Yes — scheduled triggers run on WordPress cron, which by default only fires when your site receives a visit. On low-traffic sites that means scheduled automations can run late or be skipped. We recommend disabling WordPress's pseudo-cron and pointing a real system cron job (or your host's cron feature) at wp-cron.php on a fixed interval, typically every five minutes. The setup steps are on the getting-started guide.
An automation combines one trigger with condition checks on fields relevant to that trigger — deal value, order total, customer segment, priority, pipeline, assignee and similar — and one or more of the available actions. We do not publish a hard cap on the number of conditions or actions per automation here because it depends on the trigger; the ready-made automations below show realistic, working combinations rather than a theoretical maximum.
No. Stillpoint's automations act on CRM and work-management records — creating a project, a task or a follow-up, changing a status, notifying a user, calling a webhook — not sending bulk email. If you need drip sequences or broadcast email, that runs in a dedicated marketing tool such as FluentCRM or Groundhogg, with Stillpoint's outbound webhooks handing off the trigger event. See the integrations page for how that handoff works today.
Let the rules remember, so your team doesn't have to
Deal won becomes a project. A big order becomes a VIP task. A quiet customer becomes a follow-up. Every run recorded, none of them duplicated.
Unlimited users · Flat price per site · 30-day money-back guarantee