How Automation Works
Rules that react to events or dates across every module, with AND/OR conditions, cross-module actions and dry-run testing.
What Automation does
Automation lets you set up if this, then that rules that work across the platform: when an invoice is 7 days overdue, email the client; when an urgent ticket comes in, notify the team lead; 30 days before a contract ends, alert the account manager. You build rules without code, test them with a dry run, then switch them on.
Plan: Professional and above.
How a rule is structured
1. Trigger — what starts the rule. There are two kinds:
- Something happens. Events come from every module, including:
- Tickets — created, updated, assigned, comment added, merged or split, KB article published.
- CRM — company or contact added or updated, deal created or updated, lead captured, proposal created or updated.
- Finance — invoice created or updated, payment received, contract created or updated, bill received, credit note issued, VAT return filed.
- RMM / Devices — device enrolled, backup job status changed, SSL certificate status changed, security incident raised.
- Field Service, Projects, HR, Documents, Purchasing and Compliance — for example work order created, timesheet submitted, leave request submitted, file uploaded, purchase order created, incident reported.
- On a date. A set number of days before or after a date on a record, such as a contract end date, invoice due date or SSL expiry. See Date-Based Automation.
2. Conditions (optional) — which records the rule applies to, for example only urgent tickets or only invoices over £1,000. Conditions can be grouped with AND and OR and nested, so you can express rules like priority is urgent AND (client is Acme OR category is Security).
3. Actions — what happens: send a notification or email, create or update a ticket, update the client company, create a field-service work order, run an RMM script, post to Slack, Teams, Discord or Google Chat, or send a signed webhook to your own system. One rule can have several actions, and they run in order. See Automation Action Types.
Dry-run testing
Before switching a rule on, click Test Rule (Dry Run). Plenix checks the rule against recent matching events and shows which records it would have acted on and what each action would have done, without changing anything. For date rules it lists what will fire over the next 30 days.
Example: overdue invoice chase
Trigger: On a date — 7 days after the Invoice due date
Condition: Status is not Paid
Actions: 1. Send Email to the client's billing contact
2. Send Notification to the account owner
Common patterns
- Urgent ticket alert — Ticket Created, priority equals Urgent → notify the team lead and post to the support channel.
- Contract renewal — 30 days before the contract end date → create a ticket for the account manager and email the client.
- SSL expiry — 14 days before the certificate expiry date → create a ticket to renew it.
- Proposal follow-up — 3 days before the proposal's valid-until date → remind the deal owner.
- Sync to your own tools — any event → send a signed webhook.
Automation vs AI Autonomy
| Automation | AI Autonomy | |
|---|---|---|
| Decision making | Rules you define | AI classification and playbooks |
| Actions | Across all modules | Device-level scripts, diagnostics and remediations |
| Plan | Professional and above | Enterprise |
| Set up in | Visual rule builder | Policy mode per action type |
Where to find it
Go to Settings → Automation Rules for your rules, whether each is on or off, and how often it has fired. The Templates tab has ready-made rules, and Run History shows every time a rule ran.
Where to go next
Was this article helpful?