> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/device-management/rule-engine.md). # Rules How rules apply business logic to incoming device data to send alerts, call external systems, and send downlinks. **Rules** apply business logic to incoming device data. When a condition is met, a rule triggers an action, such as sending an alert, calling an external system, or sending a downlink to a device.

A rule with a device input, a comparison logic block, and two actions — A rule linking an input, a logic block, and two actions

## Common use cases ### Logic

Use case	Example
No-code business logic	Compare a value to a threshold or to the last sample of another device with a Comparison logic block, without writing code.
Combine several inputs	Sum the people counts of several occupancy sensors with a Custom Logic block, and store the total on a separate device with the akenza DB action.
Scheduled checks	Run a rule every few minutes, every few hours, or at a fixed time with a timer, instead of on every new sample.
Geofencing	Trigger an action when a device enters or leaves a defined area with the Geofence logic block.

### Actions

Use case	Example
Alerts	Notify users by email, SMS, Microsoft Teams, or Slack when a value crosses a threshold.
Device commands	Configure or control a device with a downlink when a condition is met.
External systems	Call a REST API with a webhook.
Data management	Store or forward data only when it matches certain business logic.

## How a rule works A rule consists of three parts, which you link to each other in the rule editor:


Input	The devices, tags, or tag combinations whose data samples trigger the rule.	Input
Logic	The condition applied to the data: a comparison, or a custom script.	Logic blocks
Action	What happens when the condition is true.	Rule Actions

To link two parts, click the dot on one block. The possible destinations are shown, and a blue line connects the blocks once they are linked. ### Input An input is a **device** that has sent a data sample to akenza. Each new sample triggers the logic the input is linked to. A rule can have several inputs. You can also select a [**tag**](/device-management/managing-a-workspace/tags.md) as input. The rule then runs for every device with that tag. A **tag combination** selects the devices that match a logic expression of several tags. ### Logic The logic defines the condition that is evaluated when the rule is triggered. * The [**Comparison**](/device-management/rule-engine/logic-blocks/rule-logic.md) logic block compares device data to a constant value, to the last sample of the same device, or to the last sample of another device. You can add more data sources and conditions to extend it. * A [**Custom Logic**](/device-management/rule-engine/logic-blocks/custom-logic.md) block runs a JavaScript script for logic that a comparison cannot express. Custom logic blocks are managed at organization level and are available in all workspaces. ### Action An action runs when the logic evaluates to true. Rule actions use the same [output connectors](/device-management/your-data-flow/connectors.md) as data flows, plus [downlinks](/device-management/rule-engine/rule-actions/downlink.md). Once a rule is saved, its actions can be reused in other rules. {% hint style="warning" %} A **deactivated** rule is not triggered by new data. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.akenza.io/device-management/rule-engine.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.