> This page is for Portal. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.emnify.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.emnify.com/_mcp/server. > Use Automations, the emnify feature for event-driven rules and email notifications, in the emnify Portal. Automations allow you to define event-driven rules and take automated actions, such as email alerts. This feature is particularly useful for organizations managing large fleets of devices, offering a more responsive and observable IoT experience. For an overview of Automations as an emnify platform feature, see [Automations](/services/automations). ## Events log You can view event logs under the [**Events log** tab](https://portal.emnify.com/automations/events-log) of the new **Automations** section. This helps you to investigate device and SIM activity. You can also [customize the table view](/portal/how-tos/customize-tables), giving you full control over how your event data is displayed. The following information is available: | Property | Description | | :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Date and Time | When the event occurred, displayed in the `MMM dd, yyyy h:mm a` format (for example, Jul 30, 2025 4:55 PM). | | Severity | Indicates the importance of the event: **Info** for expected behavior, **Warning** for problems or unusual behavior that may not require immediate action, and **Critical** for serious issues requiring follow-up. | | Event type | Name of the event that occurred. This corresponds to the `description` field in the [Event type object](/developers/reference/events#event-type-object). | | Device | Name of the affected device, if applicable. Includes a link to the device's detail page. | | Network | Name of the [mobile network operator (MNO)](https://www.emnify.com/blog/mno) the device was roaming on, such as Claro or Vodafone. Shown only for network-related events. | | Country | The country where the MNO (listed under **Network**) was providing service. Shown only for network-related events. | | ICCID | [Integrated circuit card identifier](https://www.emnify.com/iot-glossary#iccid) including the final [Luhn checksum digit](https://www.emnify.com/iot-glossary#luhn-checksum-digit). | | Tags | Tags assigned to the device at the time of the event, if applicable. | | RAT | [Radio access technology (RAT)](https://www.emnify.com/iot-glossary#rat) the device was using, such as 4G or LTE-M. Shown only for network-related events. | | ID | Unique identifier for the event. Displayed in the expanded view. | | Description | A brief summary of the event, including any relevant metadata. Content varies by event type. | | Action performed by | The user who performed the action, including their name, email, and user ID. Displayed in the expanded view for [device status management events](/system-events/event-types/device-status-management). Actions performed via API or application tokens may not include user details. | > **Note** > > For each event, click anywhere on the table row to open the event details. ### Filter events Filters allow you to query events based on one or more properties (for example, time period or country). For more information and available filters, see [Filter tables in the emnify Portal](/portal/how-tos/filter-tables). ### Export the events log You can download the event logs as a CSV file for offline analysis. See [Export the events log](/portal/how-tos/manage-automations#export-the-events-log) for step-by-step instructions. ### Custom events in the events log [Custom events](#custom-events) are displayed alongside system events in the events log. They are shown with a dedicated custom event icon and the configured parameter metadata in the event description. ## Rules You can [add automation **Rules**](/portal/how-tos/manage-automations#add-a-rule) based on pre-selected connectivity events. Both [emnify system events](/system-events) and [custom events](#custom-events) are supported as rule triggers. The **Choose event type** dropdown shows which ones are currently available to your Workspace. Rules are built in the emnify Portal, accessible under the [**Rules** tab](https://portal.emnify.com/automations/rules) of the new **Automations** section. ### Custom events In addition to [emnify system events](/system-events), Automations now support *custom events*. How custom events differ from system events: * System events are predefined by emnify and require no configuration. * Custom events introduce configurable event parameters, such as thresholds or severity levels depending on the event template. #### Event parameters Unlike system events, custom events require additional configuration. Depending on the selected custom event template, you may need to set parameters such as: * Usage limits * Severity level * Other event-specific thresholds > **Warning** > > Custom event parameters cannot be edited after the rule is created. > > If you need to change a threshold or severity later, you must: > > 1. Duplicate the rule > 2. Configure the new parameters > 3. Delete the old rule if no longer needed #### Predefined targets Most events require you to define a device target. However, some custom events come with the target already predefined as part of the event template. In those cases, targeting cannot be modified. ### Device targeting Targeting allows you to define specific groups of devices to which the rules should apply. Rules can apply to: * All devices * Devices filtered by **Service Policy**, **Coverage Policy**, or **Tags** ### Email alerts You can configure email notifications to be sent when a rule is triggered. * Up to 10 subscribers per rule * Recipients don't need to be registered emnify users, but they need to [verify their email address](#email-verification-workflow). * Email content uses emnify-provided templates for consistency and clarity. * A [global daily limit of 20 emails per rule](#email-delivery-limits) is enforced to prevent spam or flooding. Each notification email includes a footer with unsubscribe instructions. ### Rule management Rules can be: * [**Paused**](/portal/how-tos/manage-automations#pause-or-resume-a-rule), which immediately stops alert notifications without deleting the rule. * [**Edited**](/portal/how-tos/manage-automations#edit-a-rule), but only the target and notification subscribers can be changed. > **Warning** > > You cannot change the triggering event once the rule is added. * [**Duplicated**](/portal/how-tos/manage-automations#duplicate-a-rule), allowing quick setup of similar automations. * [**Deleted**](/portal/how-tos/manage-automations#delete-a-rule), when it's no longer needed. ## How automations work User flow for configuring an automation: 1. **Select Event**\ Choose a supported system event or custom event to act as the rule's trigger. 2. **Configure Parameters** (custom events only)\ Set required parameters specific to the selected custom event template. 3. **Define Target**\ Specify targeting conditions (for example, device policies or tags) if not predefined. 4. **Add Actions**\ Choose from available actions (currently limited to email notifications). Then, provide the required parameters, such as the email address. Backend flow: * Events are filtered and enriched with parameters. * Matching automations are triggered. * Actions are executed via a dedicated event bus. * The status of each action is updated in the backend. ### Email verification workflow To maintain deliverability and ensure user consent, emnify enforces a verification step for non-registered email recipients: * When a new email is added to a rule, emnify checks whether it is verified. * Recipients already associated with verified emnify accounts don't require confirmation. * If unverified, the recipient is sent a confirmation email with a link to approve notifications. * This confirmation is required only once per email address, regardless of how many rules it's added to. * Until verified, no notifications are sent to that recipient. All alert emails come from a dedicated sender: `automations-do-not-reply@emnify.com`\ This separation improves deliverability and keeps transactional emails (such as MFA) unaffected. #### Email verification status You can view and manage the verification status of each email recipient directly in the **Rules** configuration UI. The following statuses are shown next to each email address: | Status | Description | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Verified | The recipient clicked the verification link and is eligible to receive notifications. | | Pending Verification | A verification email has been sent but not confirmed. No emails are delivered until verified. | | Verification Expired | The 7-day window for verification passed without confirmation. No emails are sent. | | Blocked | The address couldn't be delivered to (for example, permanent failure or bounce). Contact [emnify Support](https://support.emnify.com/hc/en-us/requests/new) for help. | If an email is **Blocked**, an inline error appears below the tag list to inform you that action is needed. #### Revoke and resend emails You can: * **Revoke** an email address at any time by removing it from the recipient list. This immediately prevents any future emails. * **Resend Verification** for addresses with **Verification Expired** status. This resets the status to **Pending Verification** and issues a new 7-day token. The **Resend verification** button only appears if expired addresses are present. New addresses trigger a verification email automatically. ### Email delivery limits To ensure reliable delivery and avoid spam filtering by email providers, emnify enforces a global email throttling mechanism: * A **maximum of 20 emails per day** can be sent for each automation rule. * If the limit is exceeded, no additional emails are sent for that rule until the next day. * The email count resets every day at midnight UTC. * Emails with multiple aggregated notifications still count as one email. * The system continues to log rule executions, but failed emails are marked in the actions log with: * **Status**: `FAILED` * **Reason**: `Mailing limit reached for automation: ${automationId}` * This limit applies only to email actions, not to other types of automation actions. This helps protect your and emnify's sender reputation with email providers. ## Key concepts * **Action**: An operation performed when an event matches a rule (for example, send email, reset connectivity) * **Target**: A filter defining which devices a rule applies to * **Workflow**: A structured, multi-step execution path for complex actions. Pre-defined by emnify or custom-defined per customer * **Workflow attributes**: Input parameters required for a workflow to run (for example, ICCID, device tag) * **Actions log**: A record of executed actions for troubleshooting and transparency. Failed email actions that exceed the daily send limit are included here. * **Automation resource**: The stored configuration linking an event trigger, a target, and one or more actions * **Email status**: The verification or delivery eligibility state of a rule notification recipient (for example, verified, pending, expired, blocked). > **Tip** > > Automations are new to emnify, so feedback and suggestions are very welcome. > Please [open a ticket on Canny](https://emnify.canny.io/).