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.
An event fires a rule, and the rule reaches people through six independent channels.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.| Channel | Reaches | Needs | Configured on |
|---|---|---|---|
| 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.
- 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. - 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/organizationand subscribe to organization-level events, rather than being attached to one machine's rule. See Send events to your own endpoint.
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.
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.
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 |
| 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 |
| A push notification for a message or a mention | Chat, which borrows the push channel and none of the rules | Overview: messaging in IoTFlows |
| 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 |
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
- 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.
- 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.
- 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 and Event types and channels.
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.