Workflow & Automation Builder
Build no-code rules that react to what happens in Knowledge ERP — pick a trigger, narrow it with conditions, and run actions like emails, SMS, tasks, approvals, and webhooks.
The Workflow & Automation Builder lets you turn "when X happens, do Y" into a rule — no code. Each rule is a trigger, optional conditions, and one or more actions, and every run is logged so you can see what fired and why.
In this section #
Detailed guides for everything covered here:
- Automation Rules — A saved "when this happens, do that" workflow — a trigger that watches for an event, optional conditions that must pass, and one or more actions that fire automatically.
- Approval Requests — Approval requests are the human gate inside your automation rules — a pending record that blocks an entity until a user approves or rejects it.
Triggers #
A trigger is the event that starts a rule. They come in three flavors:
Event-driven — fire the moment something happens:
- Sales order created
- Purchase order created
- Work order status changed
- Opportunity stage changed
Condition-based (evaluated on a schedule) — fire when something is in a state that needs attention:
- Low stock (projected to run out within its lead time — see reorder
suggestions). It runs once for each
Location where a product is running low, so a rule that sends email sends
one message per Location;
{{location_name}}says which (marked "(deleted)" for a deleted Location, and "No Location" for a reorder point without one). A Create purchase order action on a Low stock rule orders into its own Receiving Location if it names one, once per run of the schedule (a repeat in the same run skips the action; the run is still logged as a success, and its result records the action as skipped), and otherwise into each short Location. A Require approval action is kept per product: while a request for the product is pending, another Location's run doesn't open a second one. A Notify users action on a Low stock rule tells each person, by email and in the app, only about the Locations they work at: someone assigned to one Location isn't told about another's, and someone with no Location restriction, such as an Admin, is told about all of them. A Location that none of the named people works at is announced to none of the people restricted to other Locations. Send email, Send SMS and Call webhook actions go to the address, number or URL the rule names, whatever the Location. - Overdue equipment checkout
- Overdue rental
- Overdue work order
- Invoice overdue
- Invoice unpaid for N days
Time-based — fire on a cadence: daily, weekly, or monthly.
Conditions #
Conditions narrow which events actually run the rule — for example, only sales orders above a value threshold, or only a specific opportunity stage. If the conditions don't match, the rule is skipped (and that's recorded in the log).
Actions #
When a rule fires, it runs its actions:
- Send email — templated with
{{placeholders}}from the event. - Send SMS — via your Twilio connection.
- Notify users — email notifications to chosen users.
- Create task — a follow-up task with assignee, priority, and due date.
- Create purchase order — draft a PO automatically.
- Call webhook — POST the event to an external URL.
- Require approval — pause the action until a person approves or rejects it.
Approvals #
The Require approval action turns a rule into a gate. For example, a rule on purchase-order submission can hold the PO until an approver signs off — submission is blocked until then. Pending items show up as approval requests, which can be approved or rejected (including over the API).
Scheduled runs #
The condition-based and time-based triggers are evaluated by a scheduled command
(automation:run-scheduled) that runs daily. It checks for overdue checkouts,
overdue invoices, unpaid-for-N-days invoices, overdue work orders, overdue
rentals, and low-stock items, and fires any daily/weekly/monthly rules due that
day.
Execution log #
Every rule keeps an execution log — each run is recorded as pending → success / failed / skipped, with the context it saw and the result. When a rule isn't doing what you expect, the log tells you whether it fired, matched, and what happened.
Doing it from the API #
# List automation rules
curl "https://your-domain.com/api/v1/automation/rules" \
-H "Authorization: Bearer $TOKEN"