--- title: "Overview: alerts and integrations" description: "Every way IoTFlows tells someone something: the six channels a machine event rule can fire through, which of them reach a subscriber list and which change the machine for everyone, where rules and integrations are configured, and the four things that email people without being event rules at all." category: "Start here" source_url: "https://www.iotflows.com/docs/alerts/overview/" --- # Overview: alerts and integrations Every way IoTFlows can tell someone something, and which one to use when. An *event* is a condition IoTFlows watches for on one machine, such as a stop that has lasted longer than fifteen minutes. A *rule* pairs one event type with the *channels* that carry it, where a channel is one way of delivering the news: an email, a notification on a phone, a line on the machine's record. Every machine carries the same grid of ten event types, and nothing is sent until you switch a channel on. ## The six channels A rule offers six columns, and each is an independent switch. Switching two on sends two things. Diagram: A diagram in three tiers. On the left, a box headed Event reads: a machine has been stopped for 15 minutes. An arrow leads right to a box headed Rule, reading Machine Down, switched on for this machine. From the rule, six arrows fan out to the six channel columns. Email reaches the people on that event's subscriber list. Push reaches the same list, in the IoTFlows mobile app. SMS reaches the same list, by text message. Log reaches nobody and records on the machine's Health tab. Work Order opens on your maintenance board, unassigned. Integrations posts to a Slack, Teams or Discord channel. A note across the bottom reads: six independent switches per event type. Email, push and SMS reach a subscriber list; log, work order and integrations change the machine for everyone. *An event fires a rule, and the rule reaches people through six independent channels.* | Channel | Reaches | Needs | Configured on | |---|---|---|---| | **Email** | The people on that event's subscriber list | Nothing | The machine's **Event Notifications** | | **Push** | The same list, in the mobile app | The app installed, with notification permission granted at the operating system | The machine's **Event Notifications** | | **SMS** | The same list, by text message | A verified phone number on each recipient's account | The machine's **Event Notifications** | | **Log** | Nobody. It records the event on the machine's **Health** tab | Nothing | The machine's **Event Notifications** | | **Work Order** | Your maintenance board, as an unassigned work order | A maintenance board | The machine's **Event Notifications** | | **Integrations** | A Slack, Microsoft Teams or Discord channel | An *integration*, a destination created once for the whole organization | Created in **Integrations**, attached per event type | The split down the middle of that table is the one to hold on to. **Email**, **Push** and **SMS** reach people through a *subscriber list*, the members signed up to that one event type on that one machine, so the switch alone sends nothing to nobody. **Log**, **Work Order** and **Integrations** are settings on the machine, so switching one on changes what everybody sees. Choose SMS only for events someone must act on within the hour. Every channel you add to a rule lowers the attention the rule gets, and a plant where every event buzzes a phone stops reading any of them. You do not need an integration to get alerts. Email and push work with nothing configured beyond a subscriber list. **Log** costs nobody's attention at all, so turn it on for every event type you care about, including the ones you want no notification for. ## Where rules live Three surfaces, and only the first is used often. - **Per machine.** The bell on a machine's page opens **Event Notifications**, the grid of ten event types across six channels. Rules are stored on the machine, so each machine is set up separately and there is no organization-wide alert switch. See [Set alert rules for a machine](/docs/alerts/asset-event-rules/). - **Once per organization, for chat.** Create a Slack, Teams or Discord destination on the **Integrations** page at `/integrations`, then attach it to the event rules that should reach it. See [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/). - **Once per organization, for your own systems.** A *hosted endpoint* is an HTTPS URL you control that IoTFlows posts events to. Endpoints are added under `/settings/organization` and subscribe to organization-level events, rather than being attached to one machine's rule. See [Send events to your own endpoint](/docs/alerts/webhooks/). Deciding who else is told needs Owner or Administrator. Every other role sees **Email**, **Push** and **SMS** as plain switches that subscribe only themselves, and finds **Integrations** in the navigation dimmed and unclickable. See [Roles and permissions](/docs/admin/roles-reference/). ## Alerts versus work This section draws one line: if it notifies a person or a system, it is documented here. If it creates work, it is documented in the product that owns the work. **Work Order** sits on the line, so it is split. The switch is documented here, because it is one of the six columns in the same grid. The board the work order lands on, and what happens to it afterward, are in Maintain, see [Organize work on the maintenance board](/docs/maintain/maintenance-board/). Turn it on for events with one obvious response, such as a bearing fault. Leave it off for **Machine Down** and **Device Offline**: both fire routinely and usually mean a changeover, a jam or a network problem, not a repair. ## What is not an alert Four things reach people without being event rules, and none of them is configured in **Event Notifications**. | It sends | What it is | Documented on | |---|---|---| | Email at 85% of a trigger point, and a work order at 100% | A *meter*, counting runtime or cycles toward planned maintenance rather than watching for a condition | [Trigger maintenance from meter readings](/docs/maintain/meters/) | | A report, on a daily to yearly cadence | A schedule saved from a report's **Actions** menu | [Email a report and schedule it to repeat](/docs/monitoring/share-and-schedule-reports/) | | A push notification for a message or a mention | Chat, which borrows the push channel and none of the rules | [Overview: messaging in IoTFlows](/docs/messaging/overview/) | | Nothing, until somebody opens it | The **Event Alerts** feed on a machine's **Health** tab, which is what **Log** writes into | [Review and dismiss machine events](/docs/monitoring/asset-events/) | A meter is the one worth knowing about before you build rules. It emails at a trigger point you set rather than at a condition the sensor found, so "tell me every 500 hours of runtime" is a meter and "tell me when this machine stops" is a rule. ## Where to start 1. **Get one alert working end to end.** One machine, one event, yourself as the only recipient, tested by stopping the machine on purpose. See [Quickstart: get an email when a machine goes down](/docs/alerts/quickstart/). 2. **Turn on push for the people on the floor**, who are not reading email while they work. See [Turn on push notifications on your phone](/docs/alerts/mobile-push/). 3. **Fill in the rest of the grid** once you know what you want to be told about, one machine at a time. See [Set alert rules for a machine](/docs/alerts/asset-event-rules/) and [Event types and channels](/docs/alerts/event-types-reference/). If an alert did not arrive, check the subscriber list on that event type before you check anything else. An empty list fails silently, and it is the most common cause by a distance. See [Troubleshoot alerts you did not receive](/docs/alerts/troubleshoot-alerts/). ## See also - [Quickstart: get an email when a machine goes down](/docs/alerts/quickstart/) - [Set alert rules for a machine](/docs/alerts/asset-event-rules/) - [Send alerts to Slack, Teams, or Discord](/docs/alerts/chat-integrations/) - [Event types and channels](/docs/alerts/event-types-reference/)