Stage automation runs actions when a deal enters or leaves a pipeline stage, or sits in one too long. In Treepie Flow an automation can create a task, draft a quote, require fields, notify a person or team channel, or call a webhook — and act in other Treepie products, such as opening a Loop project or scheduling Books invoices when a deal is won. Every run is logged on the deal.
Because the consequences of a stage change are real work — a legal review, a kickoff, a credit check — and they are remembered reliably right up until the week somebody is busy.
Stage automation runs a defined action when a deal enters or leaves a stage: create a task, draft a quote, notify a person, open a Loop phase or raise a flag for review.
Each automation is a readable rule attached to a stage: on entry, do this. Runs are logged on the deal, so a missing task can be traced to a rule that did or did not fire rather than argued about.
Deals entering Negotiation at Harlow Logistics now open a credit check task for finance automatically. The check used to happen after signature about a third of the time, which is where the two bad debts came from.
It will not send external email on its own. Anything a customer receives goes through a person or through sequences, where the stop rules and consent state are explicit.
It writes into Loop for delivery tasks, Books for credit and billing steps, Desk for onboarding queues, and the platform notification layer for alerts.
| Checklists & memory | Generic workflow tools | Treepie Flow | |
|---|---|---|---|
| What triggers the work | Someone remembering | A separate tool watching for changes | The stage change itself |
| Actions in other products | Emails and messages | Connectors that break when fields change | Native: Loop, Books and Desk on the same record |
| Where it is recorded | Nowhere | In the workflow tool’s logs | On the deal, beside the stage change |
| Testing a change | Not possible | Varies by tool | Dry run against past stage changes |
| When it fails | Nobody notices | An error in another system | Retried, then flagged to the deal owner |
Yes, and each is logged separately so a partial failure is visible rather than silent.
You choose. Rules can fire on entry, on exit, or only on forward movement.
Yes. Rules are attached to stages, and stages belong to a pipeline.
A deal entering a stage, leaving a stage, or staying in a stage longer than a time you set. Conditions narrow it further — for example only deals over $20,000, or only in the Renewals pipeline.
Create a task, draft a quote, require fields before a deal can leave a stage, update a field, notify a person or team channel, call a webhook, or act in Loop, Books and Desk.
Yes. Actions run in the order you list them, and each is logged separately.
Admins by default. You can grant the permission to other roles, and every change to an automation is kept in the audit trail.
Only if you choose. Imports and bulk edits can run with automations off, so migrating history doesn’t send a flood of tasks.
Yes. A time-in-stage trigger acts after a delay — for example, a chase task if a deal has sat in Proposal for seven days.
Those watch one app and act in another through connectors. Stage automation runs inside the record every Treepie product shares, so there is nothing to map or keep in sync.
No. Flow actions work on their own. Cross-product actions appear when you switch those products on.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.