REDCap Alerts & Notifications

Deep-Dive Guide for Automated Notifications and Data-Triggered Messaging

Alerts & Notifications allow REDCap to send automated emails or notifications when specific data conditions are met. Unlike Automated Survey Invitations (ASIs), Alerts are not limited to survey invitations and can support a much wider range of workflows.

Alerts & Notifications vs. ASIs

Feature Alerts & Notifications ASI
Primary purpose Send automated emails or notifications based on data conditions Send survey invitations automatically
Requires a survey? No Yes
Typical use Notify staff, participants, or external recipients Deliver survey links
Logic-based? Yes Yes
Best for Workflow notifications, conditional messaging, reminders, operational alerts Follow-up surveys and scheduled invitation workflows
Simple rule: Use ASI to send survey invitations. Use Alerts & Notifications for broader automated communication workflows.
Core Principle: Alerts are triggered when specified conditions become true. They are best used when a study needs automated communication beyond basic survey invitations.
Important: Alerts can fire more than once if they are not configured carefully. Always define the triggering conditions, timing, and repeat behavior intentionally.

When to Use Alerts

Alerts are useful when you need REDCap to send emails or notifications automatically based on data activity or specific responses.

  • Notify study staff when a participant meets criteria
  • Send confirmation emails after a workflow step is completed
  • Alert a team when data are missing or incomplete
  • Notify someone when a concerning response is entered
  • Send reminders or internal operational notifications
Best Practice: Use Alerts for internal workflows, operational notifications, or conditional messaging. Do not use them as a substitute for ASIs when the goal is to manage survey invitation workflows.

How Alerts Work

An Alert is evaluated when data are saved or updated. If the logic evaluates to true, REDCap can send the notification immediately or according to the schedule you define.

  1. Data are entered or updated
  2. Alert logic is evaluated
  3. If the logic is true, REDCap schedules or sends the alert

Depending on configuration, an alert may send:

  • Immediately
  • After a delay
  • More than once
  • Only once per record
Key Concept: Alerts are driven by data state and logic, not just by survey completion.

Using Conditional Logic

Alerts use logic similar to branching logic. The alert is triggered only when the condition becomes true.

Examples:

[consent_complete] = 2
[score] > 10
[visit_date] <> ""
Important: Poorly written logic is one of the most common causes of alert errors, duplicate emails, and unintended notifications.
Best Practice: Test your alert logic first in a report, Data Quality rule, or test record workflow before activating the alert.

Timing & Scheduling

Alerts can be configured to send immediately or after a delay. Some workflows may also allow recurring or repeated sends, depending on how the alert is defined.

  • Immediate: sends as soon as the logic becomes true
  • Delayed: sends after a specified amount of time
  • Repeated: may send again if conditions remain true and repeat settings allow it
Important: Repeating alerts can generate unintended duplicate emails if the record continues to meet the same condition over time.
Best Practice: When the alert is meant to happen only once, explicitly configure it to send once per record or include a field that prevents repeated triggering.

Common Use Cases

  • Email staff when a participant is eligible for the next step
  • Notify a coordinator when consent is completed
  • Alert a PI or study team when a high-risk response is entered
  • Send a reminder when required follow-up data are missing
  • Notify an external recipient when a PDF or workflow artifact is ready
Design Tip: Alerts are often most useful when they support study operations behind the scenes rather than when they are visible to participants.

Common Mistakes

  • Using Alerts instead of ASIs to manage survey invitations
  • Not limiting the alert to send once when appropriate
  • Using overly broad or incomplete logic
  • Sending alerts to the wrong recipient field
  • Not testing the workflow before production use
Common Mistake: If your real goal is “send a follow-up survey automatically,” that is usually an ASI workflow—not an Alert workflow.

Quick Setup Checklist

  • Define the exact event or condition that should trigger the alert
  • Confirm the correct recipient email field or address
  • Set the timing intentionally: immediate, delayed, or repeated
  • Prevent duplicates by limiting sends when appropriate
  • Test the alert in Development with realistic records
  • Validate the message content and recipients before using real data
Final Takeaway: Alerts & Notifications are best used when you need REDCap to automatically notify the right person at the right time based on the right data condition.