If this happens, then that

Events to react to

A rule starts with its trigger: the event it listens for, one per rule. Those events come out of the modules themselves rather than a layer beside them, so a client you set to 'active' in a spreadsheet fires exactly the same rule as a client you set to 'active' on screen. Want to react to two things? Write two rules. Each rule carries its own on/off switch in the list, so you can silence one without deleting it. Beside these six the select carries two recipes that do nothing yet — a website's uptime toggle and a domain's status — so the rule can be built today, but nothing arrives until those modules start emitting the event.

• A task is created
• A task changes status
• A task is assigned
• A client is added
• A client changes status
• A project changes status

Conditions you click, not code you write

Under the trigger you build rows of Field, operator and Value, choosing between "All conditions must match" and "At least one condition must match". They are checked against the event and against the record it is about, so you can filter on the transition as well as on the current values. No conditions means the rule always fires. For nested all/any trees there is "Advanced: edit conditions as JSON", validated as you type. What is deliberately absent is a code box: an executable script in an admin screen on your own server is a security hole with extra steps, so conditions are declarative and stay that way.

• equals · does not equal
• is one of (values separated by commas)
• contains
• is greater than · is less than

Five actions, run in order

When the rule matches, its actions run in order in the background worker. Each action runs inside its own savepoint: if one fails, the chain stops there, only that step is rolled back, and the run is marked Failed. What the earlier steps already did stays done, because half-applied is more honest than silently undone. Other modules can contribute their own actions, so the list can grow without touching automation itself. A rule with no actions is allowed too: it matches and logs, and does nothing further.

• Create task: one loose task, or a whole task template onto the client the rule fired on
• Set task status
• Assign task
• Send notification: to the colleagues you name, in your own words
• Call webhook

A webhook that counts the answer

The webhook action posts the event, the entity type, the id and the payload as JSON to the URL you fill in — ready for n8n, Make or your own endpoint. Switch on "Wait for confirmation" and it becomes a handshake rather than a shot in the dark: the run fails unless the endpoint answers 2xx and does not reply {"ok": false}. Because that URL was typed by a person and the request leaves your own server, the hostname is resolved first and every address it resolves to must be public; loopback, private ranges and link-local are refused, redirects are not followed, and a hard timeout applies. If your automation server deliberately lives on the LAN, the operator switches that exception on explicitly.

Dry run before, run log after

Before switching a rule on you run a Dry run against the id of a real record: you see whether the conditions match and which actions would fire, and nothing is executed. After that the Run log keeps everything: when, which rule, which trigger, the status, the result per step, the error and the chain depth, filterable down to a single rule. Delete a rule and that history stays; the delete dialog says so. A run that never reached the queue, say through a Redis blip, is re-offered by a sweep instead of quietly sitting there.

• Pending · Running · Succeeded · Failed · Skipped

Rules that cannot wind each other up

A rule that creates a task fires an event another rule can react to. That is allowed, but not endlessly: an event three automation hops deep is recorded as Skipped instead of executed, so rule A → B → A shows up in the log rather than as an outage; and the same event arriving twice computes the same key and produces no second run. Writing rules is admin-only by default, because a rule acts on behalf of the organisation: it creates tasks, sends notifications and calls external endpoints. Reading rules, writing rules and reading the log are therefore three separate permissions, widened per role under Instellingen → Rollen. Automation is an extension module: the core of schakl. is open source (AGPL-3.0), extension modules need a licence key, entered under Instellingen → Licentie.