Automation Rules

An automation rule is a standing "when this happens, do that" instruction. You define a trigger (the event to watch for), optional conditions (tests that must pass), and an ordered list of actions (what to do), and Knowledge ERP runs them for you — no one has to remember to. A rule might email a customer when their invoice is 30 days unpaid, raise a purchase order when stock dips below its reorder point, or ping a Slack endpoint when a work order is finished.

A rule fires only when its trigger matches and every condition passes. With no conditions, the trigger alone is enough. The actions then run in order, and the whole run is recorded as a log — success or failure.

Rules are managed in the Automation Builder under Automation → Automation Rules.

The three parts of a rule #

Every rule is made of the same three pieces:

• Trigger — the event that wakes the rule up. Triggers are grouped by module: Inventory (stock falls below threshold, checked-out item overdue), Sales (invoice overdue, invoice unpaid for N days, new sales order), Manufacturing (work order overdue, work order status changes), Purchasing (new purchase order), CRM (opportunity moves to a stage), Rentals (rental overdue), and Scheduled (daily, weekly, or monthly). Some triggers carry extra trigger configuration — e.g. Invoice unpaid for N days asks how many days, Work order status changes lets you pick which statuses fire it, and the weekly and monthly schedules ask for a day of the week or month.
• Conditions — optional field/operator/value tests against the trigger's context. The field is a context field name like amount_due, status, or days_overdue; operators are equals, does not equal, greater/less than (or equal), and contains. All conditions must pass for the rule to fire.
• Actions — what runs when the rule fires, in order. The available actions are Send Email, Send SMS, Notify Users (in-app + email to selected users), Create Task, Create Purchase Order, Call Webhook, Require Approval, and Send Survey (send a survey invitation to an email, e.g. the customer, from the trigger context).

Email, SMS, and task fields support {{field_name}} placeholders that pull values straight from the trigger's context — e.g. Hello {{customer_name}}, your invoice {{so_number}} is overdue.

Building a rule #

From Automation → Automation Rules → New, fill in the form top to bottom:

• Name and an optional description — what the rule is for. Required name.
• Trigger type — pick from the grouped list. If the trigger needs extra setup, a Trigger Configuration section appears below it with the right fields.
• Enabled — on by default; see enabling and disabling.
• Conditions — add as many field/operator/value rows as you need, or leave the section empty to always fire.
• Actions — add at least one action and choose its type; the form then shows only the fields that action needs (recipient and body for an email, vendor/Product/ quantity for a purchase order, URL and payload for a webhook, and so on). Drag to reorder — they run in the order shown.

The Require Approval action is special: instead of acting immediately, it opens an approval request and waits for a person to approve or reject before anything downstream proceeds. It also holds the record itself. On a purchase order it sets the approval status to Pending, and Submit to Vendor is refused while it stays that way — the order does not reach the vendor because a rule said it needed sign-off.

Put spend thresholds on Purchasing: Purchase order submitted, not on New purchase order created. A PO is created header-only and its lines are added afterwards, so a Total amount >= 100000 condition on the created trigger is measured against an empty $0 order and can never match. The submitted trigger fires with the total recomputed from the order's lines.

Enabling and disabling #

A rule's Enabled toggle decides whether it runs at all. Turn a rule off to pause it without losing its configuration, its history, or its logs — far safer than deleting and rebuilding it. Disabled rules simply never fire. The rules list shows an Active indicator, the trigger, a Runs count, and when the rule last ran (or Never), and can be filtered by trigger type.

Deleting a rule soft-deletes it: the rule disappears from the list, but its logs and any approval requests it created are retained for the record.

Execution logs #

Every time a rule fires, Knowledge ERP writes an automation rule log — an immutable record of that single run. Logs are how you answer "did my rule actually do anything, and what happened?"

Each log captures:

• the rule that ran,
• a status — Pending, Success, Failed, or Skipped,
• the context the rule saw (the trigger's data at the moment it fired),
• a result payload describing what each action did or why it didn't, and
• the triggered-at timestamp.

Logs are append-only — they're never edited or deleted, so the run history stays honest. A Skipped log means the trigger matched but the conditions didn't pass; a Failed log records an action that errored (a bad webhook URL, say) along with the reason in its result. You can pull logs over the API filtered by rule or status — see the Automation Rule Logs API.

How it relates to approvals and the builder #

Automation rules live inside the broader Automation Builder, which is the home for everything event-driven in Knowledge ERP. When a rule uses the Require Approval action, it produces an approval request — a hold that a designated user must clear before the workflow continues. That keeps powerful automations (like auto-creating a purchase order) on a human leash where you want one.

Doing it from the API #

The API uses _id field names (never _uuid). Prices on the purchase-order action are entered in dollars on the form; over the API you send the JSON shapes your actions expect under actions.

# List rules, optionally filtered by trigger type and enabled state
curl "https://your-domain.com/api/v1/automation/rules?trigger_type=invoice_unpaid_days&enabled=true" \
  -H "Authorization: Bearer $TOKEN"

# Create a rule: email the customer when an invoice is 30 days unpaid
curl -X POST "https://your-domain.com/api/v1/automation/rules" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Nudge 30-day unpaid invoices",
    "trigger_type": "invoice_unpaid_days",
    "trigger_config": {"days": 30},
    "conditions": [{"field": "amount_due", "operator": ">", "value": "0"}],
    "actions": [
      {"type": "send_email", "to": "{{customer_email}}", "subject": "Invoice past due", "body": "Hi {{customer_name}}, invoice {{so_number}} is 30 days overdue."}
    ]
  }'

# Review what a rule has done (logs are read-only)
curl "https://your-domain.com/api/v1/automation/rule-logs?rule_id=RULE_ID&status=failed" \
  -H "Authorization: Bearer $TOKEN"

Logs cannot be created, updated, or deleted through the API — they only ever appear as a side effect of a rule running.