Rules and Alerts

Rules (called workflows in the UI) turn raw telemetry into action: email a group when a sensor crosses a threshold, set a device's alert state, or fire a downlink. This page covers the parts that are specific to you as a partner, authoring across a whole product line, shipping templates, and deciding what your sub-accounts can build. The hands-on builder reference (triggers, conditions, branching, actions, modulators, testing) is shared with your customers and lives in the end-user guide; this page links into it rather than repeating it.

note

Where to find it: Sidebar -> Operations -> Workflows, or a Device Profile -> Workflows tab for profile-scoped workflows.

Scopes: where a workflow applies

A workflow is a small graph of connected nodes (Trigger -> Conditions -> Actions). For how to build one, see Creating workflows. What's partner-specific is scope, you can author at five levels:

Scope	Applies to	Authored from
Device profile	every device on that profile	Device Profile -> Workflows tab
Device	one specific device	Operations -> Workflows
Sub-account	devices within one sub-account	Operations -> Workflows
Gateway	one specific gateway	Operations -> Workflows
All gateways	every assigned gateway you manage (or, authored while acting as a sub-account, that account's assigned gateways)	Operations -> Workflows

Profile scope is the most useful: it's how you say "every thermometer in this product line alerts when it gets too hot" once, instead of per device. The field picker on a profile-scoped workflow offers that profile's fields. Your PARTNER profiles are partner-side authoring only; a customer whose plan includes rules.allowSubAccountProfileRules can author profile workflows on their OWN customized profile copies (clones), which only ever fire on their own devices.

Partner admins see workflow fires across all sub-accounts in the notification bell and each workflow's fire log; a sub-account user only sees their own.

Gateway scopes watch gateway health instead of telemetry: a gateway going offline, or losing line power (see Power source). They are notify-only in this first version - email, SMS, and webhook actions fire once per incident and recover automatically, with nothing in the notification bell and nothing to acknowledge - and the all-gateways scope picks up newly assigned gateways with no per-gateway setup. The builder mechanics are in the shared reference: Gateway workflows.

Ownership: who can change a workflow

Every workflow belongs to the side that created it. Author one at partner level and it stays partner-managed: the sub-account whose devices it watches can see it (marked as managed by your workspace) but cannot edit, disable, or delete it. Author one while acting as a sub-account (the "Act as" action on Sub-accounts) and it belongs to that account, exactly as if their own admin had built it.

Ownership is fixed at creation and works both ways: from partner level you cannot edit a customer-owned workflow either. The workflow list shows an Owner column, and customer-owned rows carry an Open in ... shortcut that switches you into that account and opens the workflow there. To narrow the list by owner, use the account filter next to the search box: All accounts, your workspace only (workflows created at partner level), or a single sub-account.

Two practical consequences:

• If you want a customer to manage the alerting on their own devices, create the workflow while acting as their account (or let them build it, see the tier features below).
• A workflow may only send email or SMS to notification groups within its own scope: workflows you author at partner level use your partner-level groups; a workflow owned by a sub-account, whether their admin built it or you did while acting as that account, picks from that account's own groups only. A partner-managed profile workflow fires across many customers, so per-customer groups can't be attached to it.

Device lifecycle housekeeping happens automatically: when a device is unassigned, transferred, claimed by another account, moved to a different profile, or deleted, its active alarms clear (with the reason recorded in the alarm history and an alarm.cleared webhook), and any device-scope workflows owned by an account the device just left are disabled with an audit entry - they would otherwise keep firing with no one able to manage them. Closing a sub-account also removes its workflows, mutes, notification groups, and inbox entries.

How often a workflow notifies

Every run that passes its gates notifies. A reading arrives, the conditions pass, and the workflow's actions - in-app notification, email, text, downlink, status - all execute, every time. The platform does not ration notifications; pacing is authored, and only two things pause the human-facing sends:

• Acknowledging the alarm (ack-until-recovery): acknowledging a device's alarm is the operator's explicit "seen it, stay quiet until it is actually over." Email, text, in-app rows, and the alert chip pause for that workflow + device while the condition stays true; downlinks and multi-casts keep running. When the condition recovers, the alarm closes normally (recovery email included); the next trip is a new alarm and notifications resume in full. The pause is visible on the device's Status widget with a Resume notifications undo, and it cannot outlive its alarm: if a workflow's condition stays quiet on that device for 24 hours, the episode is treated as over and the next trip notifies in full (readings that keep the condition active count as activity even when a schedule window or throttle is holding the actions back). Disabling a workflow also resets any pause; the disable confirmation shows how many active alarms it will clear and offers a 24-hour snooze as the gentler alternative (see Saving, switching on, and pausing).
• The fire-rate ceiling, per device. maxFiresPerHour is the backstop: once a device has fired that many times in the rolling hour, further notification sends stop, while downlinks, multicasts, and the device's alert status keep running; the first fire of a new alarm is never suppressed. It's per device on purpose: one flapping sensor can't starve a profile-scope workflow for every other device. Suppressed runs show as throttled in the fire log; workflows are never disabled automatically.

Deliberate pacing is the Throttle node - a positional pass limiter that lets readings through its branch at most once per window (see Modulators in the end-user guide). Note the cost dimension: a texting workflow with no throttle sends one text per recipient per matching reading, and every text consumes SMS credits.

• Recovery is judged on the conditions, not the calendar. A workflow recovers only when every one of its field conditions is present on a reading and evaluates false; readings that simply omit the field, and closed Schedule windows, never count as recovery, so alternating frame types can't flap alarms.
• Recovery delay damps flapping. The workflow's Recovery delay setting holds the alarm open until the conditions have stayed clear for that long; on top of that, an alarm always stands at least 60 seconds after its last run before it can auto-recover.
• Recovery emails (the per-workflow toggle, plan-gated) send once per recovery, to the combined recipients of every email node on the workflow.
• Offline workflows run for devices and gateways. Workflows with a time-since-reading condition under a periodic trigger are evaluated by a platform sweep every few minutes. A silent device fires on every sweep pass under the same rules as above; the moment it reports again, the alarm recovers. Gateway offline (and power) monitoring lives on the gateway scopes and notifies once per incident instead of every pass; the old device-workflow "gateway last stats" condition never evaluated, is no longer accepted on save, and any legacy workflow still carrying it stays inert until it is recreated as a gateway-scoped workflow (the condition panel offers a one-click switch back to watching the device).

Sub-account-scope workflows now fire

Sub-account-scope workflows are evaluated on every uplink from the account's devices (they previously could be created but never ran). The rules.allowSubAccountScope tier feature gates a CUSTOMER authoring their own account-wide workflows; you can always create one at partner level (it stays partner-managed) or while acting as the account (it becomes theirs).

Because an account's fleet usually spans several device types, account-wide field conditions are limited to the universal fields: Signal Quality, RSSI, SNR, Battery, and the semantic fields (Temperature (°F), Humidity (%), and so on). A semantic condition uses the field each device's own profile tagged with that semantic, so it applies only to devices whose profile carries the tag; the rest never satisfy it. Any other device-type-specific reading belongs on a device or profile scoped workflow, where the field is guaranteed to exist. A condition-free account-wide workflow (fire on every reading) is also valid.

Battery conditions compare against the device's latest known battery level (see the battery reading for where it comes from). They are evaluated on every uplink like other conditions, and additionally the moment a fresh network battery reading arrives, so a sharp drop alerts without waiting for the device's next uplink.

Alert visibility and per-account mutes

A partner-managed workflow firing on a customer's device raises alarms both sides can see by default: the customer gets the notification, the fleet alarm, and the Status widget chip, and can acknowledge it (acknowledge clears the alarm for everyone and records who did it). Two controls tune this:

• Alert visibility (on the workflow, workspace-level authors only): switch a workflow to Workspace team only for internal monitoring the customer shouldn't see. Its alarms then stay off the customer's notifications, fleet page, and widgets entirely.
• Per-account mute (the customer's side): a customer admin can mute a partner-managed workflow for their account only. Your view is unaffected, and the workflow keeps running; you can see mutes in the audit log (rule.muted / rule.unmuted).

Templates

Ship a profile with ready-made workflows your customers can adopt. A template is a pre-authored workflow that lives on the Device Profile -> Workflows tab. A customer opens it and clicks Clone to New Rule to get a fully editable copy in their own workspace; the template itself stays untouched.

Per PROJECT_SCOPE §10, default templates ship disabled by default. The customer must clone, review, and enable them. This prevents an email storm on a freshly onboarded device.

Letting sub-accounts build their own workflows

By default, workflows are partner-managed: your customers see the alerts but don't author the rules. You can hand authoring to a sub-account through its customer tier. The relevant rule features in the tier feature bag are:

Feature	What it allows
rules.allowSubAccountScope	The sub-account can create workflows scoped to the whole account: sub-account scope for devices, and the all-gateways scope for their assigned gateways. Device-scope and single-gateway authoring on their own hardware is available to their admins regardless; each workflow is editable only by the side that created it (see Ownership above).
rules.allowSubAccountProfileRules	The sub-account can create profile-scope workflows on device profiles it owns (its customized copies). Only meaningful together with the tier's profile.allowSubAccountScope ("Sub-account device profiles"), which gates the customizing itself, plus each profile's "Sub-account cloning" setting. On a tier without profile.allowSubAccountScope, the "Device profile" scope still appears in the customer's workflow scope picker but locked, with a note that it is part of a higher plan; this is deliberate, so customers discover the feature. A customized copy's workflows only ever fire on that account's devices.
rules.allowSystemTriggers	Periodic triggers are available to author: the "device has gone quiet" sweep, and the gateway offline and gateway power workflows (which are periodic by construction).
rules.allowRecoveryEmails	A workflow can send a follow-up email when a condition recovers, not just when it trips.
rules.allowWebhook	The outbound webhook action is available.

Downlink and multicast actions follow the same downlink permissions used elsewhere (see Multi-casting). Set all of these per tier under Settings -> Sub-account Tiers; see Sub-accounts -> Setting up sub-account tiers for how the tier feature bag works and how partner-tier ceilings cap it.

Available action types

Which actions a workflow can run depends on the scope's tier. The set:

Action	Availability	What it does
Send email	Live	Emails notification groups, up to 5 individual addresses, or both.
Set device alert state	Live	Marks the device info, warning, or alert; surfaces on the device list, dashboards, and the device header.
Send downlink	Needs downlinks allowed	Sends a downlink to the device or a chosen target.
Trigger multicast group	Needs downlinks allowed	Fires a multicast group from a workflow.
Webhook	Needs rules.allowWebhook	POSTs a signed notification message to a URL on the node.

The shared Actions reference covers authoring each one. Gateway-scoped workflows offer Send email, Send SMS, and Webhook only - the device-facing actions (status, downlink, multicast) have no meaning against a gateway and are rejected on save.

The webhook action is documented in the shared reference: per-node signing secret, optional message with variables, test send, and automatic retries. Its deliveries carry the same X-Pulse-Signature / X-Pulse-Event / X-Pulse-Delivery headers as the platform's API webhooks, so one receiver implementation verifies both; see Verifying the signature. The event type is workflow.fired; gateway-scoped workflows carry a gateway object in place of device and offer the gateway token set in the message (see Message variables). If a sub-account's tier later drops rules.allowWebhook, saved webhook nodes stop sending and the fire log records why; the workflow itself keeps validating, so nothing is lost on an upgrade back.

Notification groups

The Send email action targets notification groups, named recipient lists you manage in one place, and can also send to up to 5 individual addresses typed directly on the node (external addresses included). Groups remain the right tool for anything larger: they centralize the recipient list and give each member their own email opt-out. See Notification groups for creating groups, adding members, bounce and opt-out handling, scope, and per-tier limits.

Building a workflow: the shared reference

The mechanics below are identical for you and your customers, so they're documented once in the end-user guide:

• The builder, the canvas, connecting nodes, and the Draft / Enabled / Disabled states.
• Triggers, on uplink and periodic.
• Conditions, the operators, calibrated values, and how missing readings are handled.
• Combining conditions, outside-a-range with "is not between", chained conditions (and), and parallel conditions into one action (or).
• Branching, routing different conditions to different actions (works at profile scope too).
• Modulators, schedule, sustain, and throttle.
• The webhook action, URL, signing secret, test send, and retries. For a worked example, the recipe Send workflow alerts to Microsoft Teams walks the whole path from webhook node to a card in a channel.
• Message variables, the tokens available in email, SMS, and webhook messages.
• Monitoring, the fire log and email deliveries tabs.
• Testing a workflow.

For how customers receive and clear alerts (the notification bell, acknowledging, device alert state), see Responding to alerts.

Frequently asked

Can I author a workflow that fires for many devices but emails only once per device?

Yes. Use a profile-scoped workflow with a Throttle node. Each device keeps its own cooldown, so each fires at most once per window. Coalescing into a single email across many devices isn't supported today.

A customer changed a workflow I gave them. Can I get it back?

Templates are independent of the clones made from them, so editing a clone never touches your template. Re-cloning the template gives the customer a fresh copy.