Email Notification¶

v2¶

The Email Notification block allows users to send email notifications as part of a workflow.

How This Block Works¶

Email Provider Options¶

This block supports two email delivery methods via a dropdown selector:

1. Roboflow Managed API Key (Default) - No SMTP configuration needed. Emails are sent through Roboflow's proxy service:
2. Simplified setup - just provide subject, message, and recipient
3. Secure - your workflow API key is used for authentication

4. No SMTP server required

5. Custom SMTP - Use your own SMTP server:

6. Full control over email delivery
7. Requires SMTP server configuration (host, port, credentials)
8. Supports CC and BCC recipients

Customizable Email Content¶

• Subject: Set the subject field to define the subject line of the email.

• Message: Use the message field to write the body content of the email. Message can be parametrised with data generated during workflow run. See Dynamic Parameters section.

• Recipients (To, CC, BCC): Define who will receive the email using receiver_email, cc_receiver_email, and bcc_receiver_email properties. You can input a single email or a list.

Dynamic Parameters¶

Content of the message can be parametrised with Workflow execution outcomes. Take a look at the example message using dynamic parameters:

message = "This is example notification. Predicted classes: {{ '{{' }} $parameters.predicted_classes {{ '}}' }}"

Message parameters are delivered by Workflows Execution Engine by setting proper data selectors in message_parameters field, for example:

message_parameters = {
    "predicted_classes": "$steps.model.predictions"
}

Selecting data is not the only option - data may be processed in the block. In the example below we wish to extract names of predicted classes. We can apply transformation for each parameter by setting message_parameters_operations:

message_parameters_operations = {
    "predictions": [
        {"type": "DetectionsPropertyExtract", "property_name": "class_name"}
    ]
}

As a result, in the e-mail that will be sent, you can expect:

This is example notification. Predicted classes: ["class_a", "class_b"].

Using Custom SMTP Server¶

To use your own SMTP server, select "Custom SMTP" from the email_provider dropdown and configure the following parameters:

• smtp_server - hostname of the SMTP server to use

• sender_email - e-mail account to be used as sender

• sender_email_password - password for sender e-mail account

• smtp_port - port of SMTP service - defaults to 465

Block enforces SSL over SMTP.

Typical scenario for using custom SMTP server involves sending e-mail through Google SMTP server. Take a look at Google tutorial to configure the block properly.

Cooldown¶

The block accepts cooldown_seconds (which defaults to 5 seconds) to prevent unintended bursts of notifications. Please adjust it according to your needs, setting 0 indicate no cooldown.

During cooldown period, consecutive runs of the step will cause throttling_status output to be set True and no notification will be sent.

Attachments¶

You may specify attachment files to be sent with your e-mail. Attachments can be generated in runtime by dedicated blocks or from image outputs.

Supported attachment types: - CSV/Text files: From blocks like CSV Formatter - Images: Any image output from visualization blocks (automatically converted to JPEG) - Binary data: Any bytes output from compatible blocks

To include attachments, provide the attachment filename as the key and reference the block output:

attachments = {
    "report.csv": "$steps.csv_formatter.csv_content",
    "detection.jpg": "$steps.bounding_box_visualization.image"
}

Note: Image attachments are automatically converted to JPEG format. If the filename doesn't include a .jpg or .jpeg extension, it will be added automatically.

Async execution¶

Configure the fire_and_forget property. Set it to True if you want the email to be sent in the background, allowing the Workflow to proceed without waiting on e-mail to be sent. In this case you will not be able to rely on error_status output which will always be set to False, so we recommend setting the fire_and_forget=False for debugging purposes.

Disabling notifications based on runtime parameter¶

Sometimes it would be convenient to manually disable the e-mail notifier block. This is possible setting disable_sink flag to hold reference to Workflow input. with such setup, caller would be able to disable the sink when needed sending agreed input parameter.

Common Use Cases¶

• Use this block to [purpose based on block type]

Connecting to Other Blocks¶

The outputs from this block can be connected to other blocks in your workflow.

Type identifier¶

Use the following identifier in step "type" field: roboflow_core/email_notification@v2to add the block as as step in your workflow.

Properties¶

The Refs column marks possibility to parametrise the property with dynamic values available in workflow runtime. See Bindings for more info.

Available Connections¶

Input and Output Bindings¶

The available connections depend on its binding kinds. Check what binding kinds Email Notification in version v2 has.

{
    "name": "<your_step_name_here>",
    "type": "roboflow_core/email_notification@v2",
    "email_provider": "Roboflow Managed API Key",
    "subject": "Workflow alert",
    "receiver_email": "receiver@gmail.com",
    "message": "During last 5 minutes detected {{ '{{' }} $parameters.num_instances {{ '}}' }} instances",
    "message_parameters": {
        "predictions": "$steps.model.predictions",
        "reference": "$inputs.reference_class_names"
    },
    "message_parameters_operations": {
        "predictions": [
            {
                "property_name": "class_name",
                "type": "DetectionsPropertyExtract"
            }
        ]
    },
    "sender_email": "sender@gmail.com",
    "smtp_server": "$inputs.smtp_server",
    "sender_email_password": "$inputs.email_password",
    "cc_receiver_email": "cc-receiver@gmail.com",
    "bcc_receiver_email": "bcc-receiver@gmail.com",
    "smtp_port": 465,
    "attachments": {
        "report.cvs": "$steps.csv_formatter.csv_content"
    },
    "fire_and_forget": "$inputs.fire_and_forget",
    "disable_sink": false,
    "cooldown_seconds": "$inputs.cooldown_seconds"
}

v1¶

Send email notifications via SMTP server with customizable subject, message content with dynamic workflow data parameters, recipient lists (To, CC, BCC), file attachments, cooldown throttling, and optional async background execution for alerting, reporting, and communication workflows.

How This Block Works¶

This block sends email notifications through an SMTP server, integrating workflow execution results into email content. The block:

1. Checks if the sink is disabled via disable_sink flag (if disabled, returns immediately without sending)
2. Validates cooldown period (if enabled, throttles notifications within cooldown_seconds of the last sent email, returning throttling status)
3. Formats the email message by processing dynamic parameters (replaces placeholders like {{ '{{' }} $parameters.parameter_name {{ '}}' }} with actual workflow data from message_parameters)
4. Applies optional UQL operations to transform parameter values before insertion (e.g., extract class names from detections, calculate metrics, filter data) using message_parameters_operations
5. Constructs email recipients lists from receiver_email (required), cc_receiver_email, and bcc_receiver_email (supports single email addresses or lists)
6. Processes attachments by retrieving content from referenced workflow step outputs and encoding them as email attachments
7. Establishes SSL-secured SMTP connection to the configured server (authentication using sender email and password)
8. Sends the email synchronously or asynchronously based on fire_and_forget setting:
9. Synchronous mode (fire_and_forget=False): Waits for email send completion, returns actual error status for debugging
10. Asynchronous mode (fire_and_forget=True): Sends email in background task, workflow continues immediately, error status always False
11. Returns status outputs indicating success, throttling, or errors

The block supports dynamic message content through parameter placeholders that are replaced with workflow data at runtime. Message parameters can be raw workflow outputs or transformed using UQL operations (e.g., extract properties, calculate counts, filter values). Attachments are sourced from other workflow blocks that produce string or binary content (e.g., CSV Formatter for reports, image outputs for screenshots). Cooldown prevents notification spam by enforcing minimum time between sends, though this only applies to video processing workflows (not HTTP request contexts).

Requirements¶

SMTP Server Configuration: Requires access to an SMTP server with the following configuration: - smtp_server: Hostname of the SMTP server (e.g., smtp.gmail.com for Google) - sender_email: Email address to use as the sender - sender_email_password: Password for the sender email account (or application-specific password for Gmail with 2FA) - smtp_port: SMTP port (defaults to 465 for SSL)

Gmail Users with 2FA: If using Gmail with 2-step verification enabled, you must use an application-specific password instead of your regular Gmail password. Application passwords should be kept secure and provided via workflow inputs rather than stored in workflow definitions.

Cooldown Limitations: The cooldown mechanism (cooldown_seconds) only applies to video processing workflows. For HTTP request contexts (Roboflow Hosted API, Dedicated Deployment, or self-hosted servers), cooldown has no effect since each request is independent.

Common Use Cases¶

• Alert Notifications: Send email alerts when specific conditions are detected (e.g., alert security team when unauthorized objects detected, notify operators when anomaly detected, send alerts when detection counts exceed thresholds), enabling real-time monitoring and incident response
• Workflow Execution Reports: Generate and email periodic or event-driven reports with workflow results (e.g., daily summary reports with detection statistics, batch processing completion notifications, performance metrics summaries), enabling automated reporting and documentation
• Detection Summaries: Send email summaries of detection results with aggregated statistics (e.g., email lists of detected objects, send counts and classifications, include detection confidence summaries), enabling stakeholders to stay informed about workflow outputs
• Error and Status Notifications: Notify administrators about workflow execution status and errors (e.g., send alerts when workflows fail, notify about processing completion, report system health issues), enabling monitoring and debugging for production deployments
• Data Export Notifications: Email generated data exports and reports (e.g., attach CSV reports from CSV Formatter, send exported detection data, include formatted analytics summaries), enabling automated data distribution and archival
• Multi-Recipient Updates: Send notifications to multiple stakeholders simultaneously using CC/BCC (e.g., notify team members about detections, send updates to multiple departments, distribute reports with CC for visibility), enabling efficient multi-party communication

Connecting to Other Blocks¶

This block receives data from workflow steps and sends email notifications:

• After detection or analysis blocks (e.g., Object Detection, Instance Segmentation, Classification) to send alerts or summaries when objects are detected, classifications are made, or thresholds are exceeded, enabling real-time notification workflows
• After data processing blocks (e.g., Expression, Property Definition, Detections Filter) to include computed metrics, transformed data, or filtered results in email notifications, enabling customized reporting with processed data
• After formatter blocks (e.g., CSV Formatter) to attach formatted reports and exports to emails, enabling automated distribution of structured data and analytics
• In conditional workflows (e.g., Continue If) to send notifications only when specific conditions are met, enabling event-driven alerting and reporting
• After aggregation blocks (e.g., Data Aggregator) to email periodic analytics summaries and statistical reports, enabling scheduled reporting and trend analysis
• In monitoring workflows to send status updates, error notifications, or health check reports, enabling automated system monitoring and incident management

Type identifier¶

Use the following identifier in step "type" field: roboflow_core/email_notification@v1to add the block as as step in your workflow.

Properties¶

The Refs column marks possibility to parametrise the property with dynamic values available in workflow runtime. See Bindings for more info.

Available Connections¶

Input and Output Bindings¶

The available connections depend on its binding kinds. Check what binding kinds Email Notification in version v1 has.

{
    "name": "<your_step_name_here>",
    "type": "roboflow_core/email_notification@v1",
    "subject": "Workflow alert",
    "sender_email": "sender@gmail.com",
    "receiver_email": "receiver@gmail.com",
    "message": "During last 5 minutes detected {{ '{{' }} $parameters.num_instances {{ '}}' }} instances",
    "message_parameters": {
        "predictions": "$steps.model.predictions",
        "reference": "$inputs.reference_class_names"
    },
    "message_parameters_operations": {
        "predictions": [
            {
                "property_name": "class_name",
                "type": "DetectionsPropertyExtract"
            }
        ]
    },
    "cc_receiver_email": "cc-receiver@gmail.com",
    "bcc_receiver_email": "bcc-receiver@gmail.com",
    "attachments": {
        "report.cvs": "$steps.csv_formatter.csv_content"
    },
    "smtp_server": "$inputs.smtp_server",
    "sender_email_password": "$inputs.email_password",
    "smtp_port": 465,
    "fire_and_forget": "$inputs.fire_and_forget",
    "disable_sink": false,
    "cooldown_seconds": "$inputs.cooldown_seconds"
}